Loading ...
Sorry, an error occurred while loading the content.

Re: Mailstation Emulation - Episode Four

Expand Messages
  • FyberOptic
    Shew it s late, but I wanted to post a progress report at least.   As you can see, the text is fine now!  And ironically, I still have no idea what the
    Message 1 of 20 , Jan 2, 2010
    • 0 Attachment

      Shew it's late, but I wanted to post a progress report at least.


       


      As you can see, the text is fine now!  And ironically, I still have no idea what the problem was.  What I did was actually swap out the Z80 emulation with another library.  Took some reintegrating to make it work with how this other one was designed to operate, but not too much work.  And as soon as I got it to start properly, I immediately realized it was way faster (probably since I compiled it with its assembly optimizations enabled).  And when I got interrupts working, and I got to the first warning dialog about creating a new account, I realized it was fix.  It was showing text.  And then the configuration window was too.  Great!  

      So that means there's still opcode(s) which are being handled wrong in libz80, despite all the work I did on it to fix it. And not only was it not showing text, btw, but in the Extras menu, the arrow keys were behaving all wrong as well.  I don't think I ever mentioned that.   But oh well.  I was so tired of staring at page after page of disassembled code and debug output trying to find the error that I decided trying another library was the best way to test where the problem really was.

      On an even brighter side, this new library, z80em, emulates CPU timing.  In fact, it does this so well, combined with a software interrupt related to this feature which is triggered after so many CPU cycles (which you can specify), that I was able to turn this into my main Mailstation interrupt generator.  And with a bit more timing code in place, I now have it emulating a 12mhz Z80, with 1 second time16 interrupts, and 64hz keyboard interrupts.  The cursor even blinks on the screen at the same rate as on the real hardware.  Awesome!

      After that, I tied the RTC into my PC's clock, so every time you start the emulator you get the right time.  This means you can't actually set the RTC time via the Mailstation at the moment, though.

      Trying to do something with the modem just freezes it up, as expected.  I want to figure out how better to emulate that, which I'm sure is in the datasheet if I still have it.  Wouldn't it be neat to emulate a PPP connection with that?  But aside from the modem, I haven't had any problems at all.  I've messed with all the apps, saved messages to my outbox, etc etc.  All good.

      Anyway, I've done a ton of work today cleaning up the code.  I've also added in the ability to scale the screen 2x, and to even go full-screen.  Seeing the Mailstation OS fill my monitor is both odd and neat!

      But yeah, I hope to upload a version good enough for you guys to try out tomorrow sometime.  There's just still some things I want to add before I do (like figure out why I have to push the power button twice to turn it off).  For now it'll prolly stay locked at 12mhz, and the interrupt speeds won't be changeable or anything, since there's some experimenting I want to do on the real hardware first to see if I can better understand things.  And considering how well the emulation is going right now, I can prolly test out some code on my PC now before sending my test apps to the Mailstation.  Which is what I wrote this for to begin with!


    • FyberOptic
      I think I ve finally prettied up a version of the emulator well enough to release. But until I get a better page for it, here s the directory index:
      Message 2 of 20 , Jan 2, 2010
      • 0 Attachment
        I think I've finally prettied up a version of the emulator well enough to release. But until I get a better page for it, here's the directory index:

        http://www.fybertech.net/mailstation/emulator/


        The quick start instructions are: download msemu_v01.zip and codeflash.bin, extract the ZIP, and drop the .BIN into the folder with it. Then run msemu.exe.

        Make sure to look at the readme.txt for info on the keys! You can switch between 2X size and even go fullscreen.

        In that directory index above, codeflash.bin is the same as ms253.bin, which is v2.53 of the Mailstation firmware. ms303a.bin is v3.03a, which is slightly different. I didn't include any of these in the ZIP because it's probably against copyrights for me to even have them on the website.

        The emulator looks for a "codeflash.bin" by default to work, so you can either rename other firmwares to this, or you can specify an alternate filename on the command line (or just drag the .BIN onto the EXE to launch with it). This lets you try out different versions, or even your own replacement.

        I've included a "dataflash.bin" with some generic settings, just so that you can go straight to the main menu when you start it. If you like, you can delete that file, and it'll generate a fresh one the next time you start it.

        Note that the intro screen's text colors should be yellow, and the default LCD color should be green (check the readme on how to change). If they're not for you, let me know!

        I'd appreciate feedback, particularly on any problems you might find. There's obviously a lot still not emulated, but apparently there's plenty to make the OS itself run. Just keep in mind that it'll probably freeze up if you try to use the modem!
      • cyranojones_lalp
        ... Hmmmmm... What the heck am I gonna do with an exe... The most recent windows I have is 98, and I have not booted that box up in like a year. I promised
        Message 3 of 20 , Jan 5, 2010
        • 0 Attachment
          > Then run msemu.exe.

          Hmmmmm... What the heck am I gonna do with an exe...

          The most recent windows I have is 98, and I have not booted that
          box up in like a year. I promised myself the next time I boot
          it, I will back it up. Sooooooooo, I have just been avoiding
          booting it. And I don't even know if your prog will run
          on it.

          Then I thought about this thin client I have here, with
          win XPe on it, running my magicjack. But it does not
          have enough space. I guess I could copy the files to a
          thumb drive.....

          Then I wondered if it would run with wine, under Ubuntu.

          It does! Pretty neat!!!

          > You can switch between 2X size and even go fullscreen.

          Seems they are reversed with respect to keys in readme.

          > The emulator looks for a "codeflash.bin"

          I made a copy of (what I believe is) the 253yr from yahoo group,
          renamed it codeflash.bin.

          Seems to work fine, but I get a different checksum in emulator
          than on an actual 253yr unit I have here. Funny thing is, I am
          pretty sure I verified Don's dump with an actual 253yr several
          years ago, and it matched. But it prolly was not this exact
          same unit. Maybe I changed something in the image I am
          working with, and forgot??????

          I get 91ff on my actual unit, and 9254 with my image file.
          What checksum do you get emulating your 253yr image?

          > Note that the intro screen's text colors should be yellow,
          > and the default LCD color should be green (check the readme
          > on how to change). If they're not for you, let me know!

          Colors are ok, and can change with the ctrl keys. Took me
          a bit of head scratching to figure out I needed the right-side
          ctrl key. You need to make black chars on light-green-tinted
          background one of the options! ;-)

          > I'd appreciate feedback, particularly on any problems you
          > might find. There's obviously a lot still not emulated,
          > but apparently there's plenty to make the OS itself run.

          Calculator works. Typed a new message, saved it in outbox,
          and opened it up again. Even goes into test mode, and passes
          several tests. The modem test failed, but did not lock it up.
          (Did not try to send email, though.)

          Noticed that it remembered it was in test mode (not sure
          if I quit emu, or just "power cycled it).

          Could not finish keyboard test, is there an "@ key", size, or
          spell check. Or "get mail" button?

          I would prefer that "back" was mapped to "esc", I closed
          emulator by accident more times than I can count. Esc just
          seems more intuitive for back. Maybe just make "power" quit
          emu??? Or only quit when in "off" mode???

          As for why it needs 2 presses, maybe it has something to do
          the fact that the "power" does not really go away after the
          first press? There is a flip-flop chip on the ms board that
          actually kills power.

          It would be a lot more fun if I could tweak emu code.
          For instance, I notice that whenever I press a key in
          calculator app, emu prints message on text console
          "dataflash write". It would be fun if it said what
          address was written.

          I also think it would be fun to compile a Linux version.

          I don't know if it is emulator, or wine, but the combo
          is sucking up over 50% of dual 2.5 GHz AMD cpu.
          OK, top sez emu itself is taking over 40% of one cpu,
          and Xorg is taking over 35%, and wine about 20%.

          Also, I don't know just which program crashed, but it
          seems like it was when I was trying to switch out of
          "full screen" mode. Took out the X server, and any
          program that was running under X. Linux text consoles
          were still there, along with a great deal of programs
          just listed with "2009" as the start time in process list.

          First time this box ever crashed in the ~1 year since I
          put it together. I rebooted the whole thing, but maybe
          I could have restarted X. Seemed like a good time for a
          reboot, though! (I don't think I have rebooted more that
          5 times since built, and it is up 24-7). Took over half
          hour to check the disk, I don't really want to do a lot
          of testing as to just what makes it crash. I think I
          will avoid the full screen mode, and see if that helps.

          CJ
        • FyberOptic
          ... Yeah I had it working fine in Wine on Debian when I tried it, and figured any Linux folks could just do that to try it out. ... As soon as you said that, I
          Message 4 of 20 , Jan 5, 2010
          • 0 Attachment
            --- In mailstation@yahoogroups.com, "cyranojones_lalp" <cyranojones_lalp@...> wrote:
            >
            > Then I wondered if it would run with wine, under Ubuntu.
            >
            > It does! Pretty neat!!!

            Yeah I had it working fine in Wine on Debian when I tried it, and figured any Linux folks could just do that to try it out.


            >
            > > You can switch between 2X size and even go fullscreen.
            >
            > Seems they are reversed with respect to keys in readme.

            As soon as you said that, I remembered that I forgot to update the readme when I decided to swap those keys around.


            >
            > Seems to work fine, but I get a different checksum in emulator
            > than on an actual 253yr unit I have here. Funny thing is, I am
            > pretty sure I verified Don's dump with an actual 253yr several
            > years ago, and it matched. But it prolly was not this exact
            > same unit. Maybe I changed something in the image I am
            > working with, and forgot??????
            >
            > I get 91ff on my actual unit, and 9254 with my image file.
            > What checksum do you get emulating your 253yr image?

            I only have one Mailstation, the demo unit which runs v3.03a (mail servers can even be set in the configuration). For that version, the hardware gives me a checksum of 0x53d4, but the emulator is showing 0x53e5 when I run the same firmware.

            I also noticed that my hardware seems to freeze up after getting to that point, where as the emulator continues on to a battery test.

            No idea what's going on with either of these things yet. I even tried removing my bounds-limiting for the codeflash (it forces an address wrap at 1MB like I'm assuming the real hardware does on pages 64 and up), just in case, and it gave the same results.

            I'd have to dig through the ROM Test code to see if the codeflash is the only thing it's testing, or if there's something else being added into the result somehow.


            >
            > Could not finish keyboard test, is there an "@ key", size, or
            > spell check. Or "get mail" button?

            None of those buttons are assigned yet, since I wasn't sure what to assign them to. I didn't need'em for the testing I was doing at the time, either. But you should be able to assign these to other things now, which I'll get into in a bit.

            I'll probably want to assign "Get Mail" soon though, since I've been working on trying to emulate the modem chip, and at the moment I have to keep going into the outbox to trigger the modem.


            >
            > I would prefer that "back" was mapped to "esc", I closed
            > emulator by accident more times than I can count. Esc just
            > seems more intuitive for back. Maybe just make "power" quit
            > emu??? Or only quit when in "off" mode???

            I did consider changing it to escape a few times, but as I was testing, I found hitting escape right quick to get back out of it was easier for the time being. I'll change exit to right-control + Q or X or something eventually I guess.

            The reason "power" doesn't exit is because I want to be able to simulate powering on and off.


            >
            > As for why it needs 2 presses, maybe it has something to do
            > the fact that the "power" does not really go away after the
            > first press? There is a flip-flop chip on the ms board that
            > actually kills power.

            Na, it's taking the two presses to finally acknowledge it, which then runs the shutdown function in the firmware, which toggles the bit in port 0x28 for that flip-flop. I'm actually emulating this bit, and "powering off" when it's changed.

            It seems that the Mailstation waits for the state of the power button to change somehow before acknowledging it again as being pressed. Sometimes, for example, if you hold F12 while the system is booting, then let it go once you're at the menu, then you only have to press it once to power off. I tried various ways to replicate this behavior automatically, but I didn't have much luck yet. I'm thinking it might have something to do with the signal bouncing of the real hardware, since the power button isn't handled for bouncing like the rest of the keyboard keys are in the keyboard routine.

            Hitting the button twice is a minor inconvenience though so I've worked on other stuff for the time being instead.


            Something interesting of note is that when you power off and power back on, normally the hardware would retain the RAM contents to my knowledge. Well when I was retaining their contents, the MS would check some ports during startup, before anything was even on the screen (or even before the screen was on?), and then shut itself back down again. Every time you'd try to power it back on this would happen. The only solution for the time being is clearing the ram contents at any power-off until I figure out what the Mailstation is doing.


            >
            > It would be a lot more fun if I could tweak emu code.
            > For instance, I notice that whenever I press a key in
            > calculator app, emu prints message on text console
            > "dataflash write". It would be fun if it said what
            > address was written.

            The text you see in the console is just very basic output. The "dataflash write" message was actually indicating that the emulator was writing the dataflash contents out to the file, not that the Mailstation was currently modifying the contents at that exact moment (though pretty close to it). It doesn't write out the file for every individual modification, for performance reasons.

            However, there are debug messages for that, which will not only tell you the current PC when the write is occuring, but also the dataflash address and value being written. Same for sector erases. The debug messages won't work in the version you're using since I removed the ability when cleaning up code before. But in v0.1a, you can put /console and/or /debug on the command line. The former spits all IO and other activity to the console, the latter spits it out to a "debug.out" file.

            Ever since I changed CPU emulation libraries, the debug output has dramatically reduced, since I'm no longer dumping constant disassembly as well. But the tons of IO port requests are still a mess! Eventually I'll let one limit which ports they're interested in.


            >
            > I also think it would be fun to compile a Linux version.

            As it just so happens, v0.1a not only includes the source, but will compile under Linux.

            As for changing the Mailstation keys as I mentioned earlier, there's an array which holds all the mappings, but you'll probably need that "mailstation_keyboard.html" file I got somewhere before to know which key is what. I'm betting you have it though!


            >
            > Also, I don't know just which program crashed, but it
            > seems like it was when I was trying to switch out of
            > "full screen" mode. Took out the X server, and any
            > program that was running under X. Linux text consoles
            > were still there, along with a great deal of programs
            > just listed with "2009" as the start time in process list.
            >

            I didn't have any crashes under Debian when using it with Wine. Full-screen mode semi-worked, but didn't actually go full screen. It just kind of replaced most of the desktop (but stayed crammed underneath the menu bar). That's about what I expected, even though that sucks.

            Ironically, it wasn't until I compiled a native Linux binary that I had the full-screen mode crash the application when switching back and forth several times. Even full-screen under a native binary still didn't work right, though.

            But to be blunt, this is Linux after all, and it's notorious for being problematic at running things full-screen. I've had a lot of trouble with other applications running that way in the past. So your advice of "only in a window" seems the best route, since there's really nothing I can do about it. Going full-screen is all handled through SDL calls.

            That said, console output is faster under Linux than in Windows! I found that a little surprising.



            Anyway, you can grab the newer version here:

            http://www.fybertech.net/mailstation/emulator/msemu_v01a.zip

            If you have any trouble building it, you can check the build.txt, or give me a holler and I'll try to help.
          • cyranojones_lalp
            ... Try inverting the sense of power-button input bit. Instead of: case 0x09: return (byte)0xE0 | ((power_button & 1)
            Message 5 of 20 , Jan 7, 2010
            • 0 Attachment
              --- FyberOptic wrote:
              >
              > It seems that the Mailstation waits for the state of the power
              > button to change somehow before acknowledging it again as being
              > pressed.
              > Sometimes, for example, if you hold F12 while the system is
              > booting, then let it go once you're at the menu, then you only
              > have to press it once to power off. I tried various ways to
              > replicate this behavior automatically, but I didn't have much
              > luck yet. I'm thinking it might have something to do with
              > the signal bouncing of the real hardware, since the power
              > button isn't handled for bouncing like the rest of the
              > keyboard keys are in the keyboard routine.
              >
              > Hitting the button twice is a minor inconvenience though so
              > I've worked on other stuff for the time being instead.

              Try inverting the sense of power-button input bit.

              Instead of:
              case 0x09:
              return (byte)0xE0 | ((power_button & 1) << );
            • cyranojones_lalp
              ... try: case 0x09: return (byte)0xE0 | ((~power_button & 1)
              Message 6 of 20 , Jan 7, 2010
              • 0 Attachment
                > --- FyberOptic wrote:
                > >
                > > It seems that the Mailstation waits for the state of the power
                > > button to change somehow before acknowledging it again as being
                > > pressed.
                > > Sometimes, for example, if you hold F12 while the system is
                > > booting, then let it go once you're at the menu, then you only
                > > have to press it once to power off. I tried various ways to
                > > replicate this behavior automatically, but I didn't have much
                > > luck yet. I'm thinking it might have something to do with
                > > the signal bouncing of the real hardware, since the power
                > > button isn't handled for bouncing like the rest of the
                > > keyboard keys are in the keyboard routine.
                > >
                > > Hitting the button twice is a minor inconvenience though so
                > > I've worked on other stuff for the time being instead.
                >
                > Try inverting the sense of power-button input bit.
                >
                > Instead of:
                > case 0x09:
                > return (byte)0xE0 | ((power_button & 1) << );

                try:
                case 0x09:
                return (byte)0xE0 | ((~power_button & 1) << );

                (I was trying to enter a tab in previous post, and all of a
                sudden it said "message sent" or something to that effect.
                I think the tab moved the focus from the message box over to
                the "send" button.)

                I have not tried to compile it myself just yet, been looking
                over docs for sdl.

                CJ
              • cyranojones_lalp
                ... I m sure fyberoptic knows what I meant, but if (by any stretch) there is anyone else reading this, the 4 got clipped. It wrapped to next line, and when I
                Message 7 of 20 , Jan 7, 2010
                • 0 Attachment
                  > > Instead of:
                  > > case 0x09:
                  > > return (byte)0xE0 | ((power_button & 1) << );
                  >
                  > try:
                  > case 0x09:
                  > return (byte)0xE0 | ((~power_button & 1) << );

                  I'm sure fyberoptic knows what I meant, but if (by any stretch)
                  there is anyone else reading this, the "4" got clipped.
                  It wrapped to next line, and when I edited to fit on one line,
                  I musta deleted it.

                  So, this is what I should have typed:
                  case 0x09:
                  return (byte)0xE0 | ((~power_button & 1) << 4);

                  I think it is too early for my brain.

                  CJ
                • FyberOptic
                  ... Doh, I inverted the main keyboard keys, but never thought to do it for the power button. Goes off with one tap now! Nice find! ... over docs for sdl. If
                  Message 8 of 20 , Jan 7, 2010
                  • 0 Attachment
                    --- In mailstation@yahoogroups.com, "cyranojones_lalp" <cyranojones_lalp@...> wrote:
                    >
                    > Try inverting the sense of power-button input bit.
                    >
                    > Instead of:
                    > case 0x09:
                    > return (byte)0xE0 | ((power_button & 1) << );
                    >

                    Doh, I inverted the main keyboard keys, but never thought to do it for the power button. Goes off with one tap now! Nice find!



                    >I have not tried to compile it myself just yet, been looking
                    over docs for sdl.

                    If you're using any Debian-based distro (you said you're in Ubuntu, so you are), then you should be able to grab the development packages of SDL and SDL_gfx through APT. I'm not for sure what repository it came from (hopefully one which is enabled by default), but just search for the package "libsdl-gfx1.2-dev". When you install it, it should automatically pull "libsdl1.2-dev" too. It did for me under Debian. Saved me the trouble of fetching/compiling them manually. Only thing you'll still have to compile separately is Z80em, which is a simple "make" job, pretty much.
                  • cyranojones_lalp
                    ... OK, I got all the pieces installed the other day, and got it compiling and running here, too! :-) :-) :-) :-) :-) :-) :-) :-) I had to change one
                    Message 9 of 20 , Jan 9, 2010
                    • 0 Attachment
                      --- FyberOptic wrote:
                      >
                      > Doh, I inverted the main keyboard keys, but never thought
                      > to do it for the power button. Goes off with one tap now!
                      > Nice find!

                      OK, I got all the pieces installed the other day, and got it compiling
                      and running here, too! :-) :-) :-) :-) :-) :-) :-) :-)

                      I had to change one line in Makefile to get it to fly with 64 bit cpu:

                      I changed
                      "objcopy -I binary -O elf32-i386 --binary-architecture i386 rawcga.bin rawcga.o"

                      to
                      "objcopy -I binary -O elf64-x86-64 --binary-architecture i386 rawcga.bin rawcga.o"

                      because the linker refused to link the 32 bit font file with the 64 bit
                      emulator object file. It was pretty easy to figure out the "-O elf64-x86-64",
                      but it took a lot of reading to find out that you needed to use
                      "--binary-architecture i386" for either 32 or 64 bit. Go figger.

                      > If you're using any Debian-based distro (you said you're in Ubuntu, so you are),
                      > then you should be able to grab the development packages of SDL and SDL_gfx through
                      > APT. I'm not for sure what repository it came from (hopefully one which is
                      > enabled by default), but just search for the package "libsdl-gfx1.2-dev".
                      > When you install it, it should automatically pull "libsdl1.2-dev" too.
                      > It did for me under Debian. Saved me the trouble of fetching/compiling
                      > them manually. Only thing you'll still have to compile separately is Z80em,
                      > which is a simple "make" job, pretty much.

                      Well, that was really good to know! I didn't even think to check if it
                      was in repo. Turns out libsdl1.2 was already installed, possibly 'coz xmame
                      required it. I just checked off the boxes (in synaptic) for the dev files,
                      and the libsdl-gfx1.2-dev, and "applied" it.

                      I made the change to cflags you suggested for z80em, and did "make all". I
                      got a boatload of "type mismatch" warnings, but it still works.

                      I mentioned that the windows version was sucking up close to 100% of cpu,
                      spread across 3 processes (msemu, wine, and I think xorg). This native
                      Linux build is still sucking up 100%, but just in the one msemu process!

                      I don't think it would stop anything else from running, it's prolly just
                      using it 'coz it is available. But it sure is making the cpu hotter than
                      normal!!! It usually reads below 90 degrees F, but with cpu at 100% it
                      was running over 110 F!!!!! I even think I could smell the difference,
                      but that may just have been my imagination. :-)

                      So, I looked at source, to see if I could see anything to optimize.
                      The first thing I tried was moving the call to system time, so it only
                      happens when one of the time ports is read. Didn't make a noticable
                      difference, though.

                      Next, I looked at the main loop. Seems that's the source of the
                      infinite appetite for cpu cycles. The cpu just keeps running that loop,
                      as fast as it's little pins can carry it. :-) :-)

                      I made an asumption that the main loop was cyling much faster than
                      necessary, so I added a "sleep(1)" to the loop. Well, turns out
                      sleep's units are "seconds", so I guess you know that did not come
                      out too good. So I tried sleeps little brother, "usleep", which
                      sleeps microseconds. Works like a charm!!!

                      I tried usleep(1) through usleep(1000), with only barely perceptible
                      lag noticable with 1000 usec. I don't know if perhaps it is getting
                      woke up before the 1000 usec, by some other event/interrupt. But
                      I am currently settled in on 100 usec, because there is a "diminishing
                      return" effect on the cpu load reduction.

                      With usleep(100), it idles at about 4 or 5 percent, and spikes
                      higher when mailstation code is actually doing something. If
                      I lean on the right-arrow key while in main menu, the ms icon
                      highlighting cycles repeatedly across the screen, and cpu
                      usage goes to about 10 to 15 percent.

                      If I am understanding how the code works, it seems that the z80
                      emulation is being called every 16 milliseconds. Is that right?
                      (deleted rambling)
                      At this point, I did a "sleep(30000)" on the wetware processor.

                      Oh, I think I get it, z80_Execute() runs Z80_IPeriod = 187500
                      T states each call. That makes more sense now... I was
                      wondering why it still worked with such large sleep times!
                      (Amazing how a little sleep can make things clearer!)

                      On another front, I did quite a bit of fiddling with the screen
                      color. First, I "inverted" the colors, making the background
                      the bright pixels, and text the darker. Then I made the
                      green (now a green background) a very light green tint, a
                      quite passable imitation of the actual LCD.
                      That took a few minutes.

                      Then I spent a few more hours tweaking the colors! :-)

                      I made all 5 of your color modes into various off-white tinted
                      backgrounds with black foreground,
                      and added a sixth choice, with bluish
                      foreground, and same green tinted background (ala earthlink
                      version of 120 & 150).

                      It's really kind of interesting how fast your eyes normalize
                      any of the tints to seem "plain white".

                      CJ
                    • FyberOptic
                      ... Ah okay, never even thought of that being a possible problem. I don t have a 64-bit CPU, myself. I figure the simplest solution for future versions, now
                      Message 10 of 20 , Jan 10, 2010
                      • 0 Attachment
                        --- In mailstation@yahoogroups.com, "cyranojones_lalp" <cyranojones_lalp@...> wrote:
                        >
                        > I had to change one line in Makefile to get it to fly with 64 bit cpu:
                        >
                        > I changed
                        > "objcopy -I binary -O elf32-i386 --binary-architecture i386 rawcga.bin rawcga.o"
                        >
                        > to
                        > "objcopy -I binary -O elf64-x86-64 --binary-architecture i386 rawcga.bin rawcga.o"
                        >

                        Ah okay, never even thought of that being a possible problem. I don't have a 64-bit CPU, myself. I figure the simplest solution for future versions, now that I know that I converted the font data properly, is to just encode it into a C header file and let it compile with the source.

                        The reason I included my own font to begin with is so that it would look the same regardless of platform. And for the record, this is the same font style that I use in my FyOS software on the Mailstation. It's the classic 8x8 font that CGA video cards used to use. I'm partial to it both for nostalgia's sake as well as the fact that it's very divisible into most screen sizes. The Mailstation gets a 40x16 text display out of it, similar to many old computers.



                        >
                        > I made the change to cflags you suggested for z80em, and did "make all". I
                        > got a boatload of "type mismatch" warnings, but it still works.

                        Yeah I got those too, but it's no problem. The source was likely written under an earlier version of GCC.



                        >
                        > I mentioned that the windows version was sucking up close to 100% of cpu,
                        > spread across 3 processes (msemu, wine, and I think xorg). This native
                        > Linux build is still sucking up 100%, but just in the one msemu process!
                        >
                        *snip*
                        >
                        > With usleep(100), it idles at about 4 or 5 percent, and spikes
                        > higher when mailstation code is actually doing something. If
                        > I lean on the right-arrow key while in main menu, the ms icon
                        > highlighting cycles repeatedly across the screen, and cpu
                        > usage goes to about 10 to 15 percent.

                        I never noticed it hindering my machine as I worked so I never even thought to check. Yet I've had to use usleep in daemons before so you'd think I would remember how important some CPU idle time in there can be!

                        The easiest cross-platform fix is:

                        #ifdef WIN32
                        Sleep(1);
                        #else
                        usleep(1000);
                        #endif

                        Windows doesn't have less than 1 millisecond sleep unless you get into high-definition timers, and that's a bit overkill. From my momentary tinkering I didn't notice any real difference in performance by having a whole millisecond delay.


                        >
                        > Oh, I think I get it, z80_Execute() runs Z80_IPeriod = 187500
                        > T states each call. That makes more sense now... I was
                        > wondering why it still worked with such large sleep times!
                        > (Amazing how a little sleep can make things clearer!)

                        I just did some quick math for the number. The Mailstation OS always runs at 12mhz, so 12000000 / 64 = 187500. 64 being the frequency of the keyboard interrupt I determined before. When all the specified CPU cycles are used, the Z80_Interrupt() function is called. This function automatically fires the Mailstation keyboard interrupt (if it's enabled) 64 times a second. Also, after 64 counts of this function executing, the Mailstation time16 interrupt gets fired.

                        Whenever I get around to implementing support for various CPU and (presumably) RTC timer speeds, these values will be dynamic rather than hard-coded like they are now. I'd rather know more about the I/O port functionality for setting these speeds beforehand, but I haven't gotten around to tinkering on the hardware again yet either.



                        >
                        > I made all 5 of your color modes into various off-white tinted
                        > backgrounds with black foreground,
                        > and added a sixth choice, with bluish
                        > foreground, and same green tinted background (ala earthlink
                        > version of 120 & 150).
                        >

                        I'd be curious to see your color schemes, if you want to take screencaps or whatever. I've never even seen the screen to any other model than the one I have.


                        One of the next features I want to implement is a configuration file, where people can just setup the keyboard/colors/etc from there instead of needing to recompile it.
                      • cyranojones_lalp
                        (Reply is below the screenshots) The pix are 1024 x 768, click for full size, or view image if clicking doesn t work. This is the green tinted background.
                        Message 11 of 20 , Jan 12, 2010
                        • 0 Attachment
                          (Reply is below the screenshots)

                          The pix are 1024 x 768, click for full size, or "view image" if clicking doesn't work.


                          This is the green tinted background. 
                          The ide shows some of the code mods.
                          (By the way, the ide is "Geany" and it is in Ubuntu repo.)



                          This is white background, with black text.
                          I don't really like the greenish-tint, even though the mailstation
                          actually is greenish.   I re-arranged the sdl-event handling with nested switches.



                          All 6 colors running at same time! 
                          The backgrounds are much brighter than the actual mailstation LCD, but I don't think I
                          would want to make them much darker.  I don't really care for the red or green tints, but
                          yellow and bluish are ok.  The "new" 120/150 LCD is the greenish one below the white.




                          One other code change not shown above, to writeLCD function:

                          lcd_data8[n + (x * 8) + (lcdaddr * 320)] = ((val >> n) & 1 ? LCD_fg_color : LCD_bg_color);

                          When I was figuring out how it worked, I changed some of
                          the param names in that function to these:

                          writeLCD(ushort lcdaddr, byte val, int lcdhalf)

                          But the only change to logic was to split the color var into two (fg & bg)

                          <more comments inline below>

                          --- FyberOptic wrote:
                          >
                          > Ah okay, never even thought of that being a possible problem. 
                          > I don't have a 64-bit CPU, myself.  I figure the simplest solution
                          > for future versions, now that I know that I converted the font data
                          > properly, is to just encode it into a C header file and let it compile
                          > with the source.

                          Oh, yeah, that would be better than fiddling with makefile.  I was
                          thinking of adding option to makefile, but that would still need
                          to be edited to pick version.  Just compiling it in would avoid the
                          config hassle.  I actually did something similar with your cga
                          font, I edited it into "cgafont.s" (the db's from your cgafont.inc,
                          with a label at the head) to allow sdcc code to link with it:

                              .module cgafont
                           
                              .area _CODE
                           
                          _cgafont_data::
                              .db #0x00, #0x7e, #0x7e, #0x36, #0x08, #0x1c, #0x08, #0x00
                                  etc. etc.
                           
                          > And for the record, this is the same
                          > font style that I use in my FyOS software on the Mailstation. 

                          I already guessed that.  :-)

                          > > With usleep(100), it idles at about 4 or 5 percent,

                          > I never noticed it hindering my machine as I worked so I never even
                          > thought to check. 

                          I didn't notice any sluggish behavior, but I have the "system monitor"
                          added to gnome desktop's toolbar, so whenever that drops down, it's
                          right there.  CPU temps and system temps, too.  (see screenshot
                          with 6 mailstation emulators running.)

                          > Yet I've had to use usleep in daemons before so
                          > you'd think I would remember how important some CPU idle time in
                          > there can be!
                          >
                          > The easiest cross-platform fix is:
                          >
                          > #ifdef WIN32
                          >         Sleep(1);
                          > #else
                          >         usleep(1000);
                          > #endif

                          Looks good!  (So sleep is in ms on win32?  I think it is in sec on Linux.)
                           
                          > Windows doesn't have less than 1 millisecond sleep unless you get into
                          > high-definition timers, and that's a bit overkill.  From my momentary
                          > tinkering I didn't notice any real difference in performance by having
                          > a whole millisecond delay.

                          1 ms seems fine to me.  It's not till you get up over 20 ms that it really
                          starts to get bad.  Actually, right before 16 ms, the delay goes back
                          to un-noticable.  Seems the emulation of the "slice" is happening in
                          less than a millisecond, so most of the 16 ms is just waiting.

                          The delay peaks around usleep(15300) or so, and at 15400, it drops
                          back to un-noticable.  (This is on dual 2.5 GHz AMD processor).
                          For a default, 1 ms seems good for just about any cpu speed.
                          Maybe you can make it a runtime config option?

                          I used the highly scientific procedure of counting "thousands",
                          from power-on to splash, and I don't quite get to the "s" in "one thousand two"
                          with 1-500 us range.  Seems I can get to "thous" at 1000 us, and "thousan"
                          at 5000 us.  At 10,000 us I can just about get the whole "one thousand two"
                          out.  On a real mailstation I get the same as the 500us and lower,

                          > > Oh, I think I get it, z80_Execute() runs Z80_IPeriod = 187500
                          > > T states each call.  That makes more sense now... I was
                          > > wondering why it still worked with such large sleep times!
                          > > (Amazing how a little sleep can make things clearer!)  
                          >
                          > I just did some quick math for the number.  The Mailstation OS always
                          > runs at 12mhz, so 12000000 / 64 = 187500.  64 being the frequency of the
                          > keyboard interrupt I determined before.  When all the specified CPU cycles
                          > are used, the Z80_Interrupt() function is called.  This function automatically
                          > fires the Mailstation keyboard interrupt (if it's enabled) 64 times a second. 
                          > Also, after 64 counts of this function executing, the Mailstation time16
                          > interrupt gets fired.

                          Are we in agreement that the emulator runs at "12 MHz" only because
                          you call it every 16 ms, and it runs Z80_IPeriod = 187500 T-states
                          every time it is called?

                          Just for kicks, I just now changed it to call z80_execute every time
                          thru the main loop, with no usleep,  Now the mailstation code is
                          running at warp 11!!!  I'm not sure, but I think it is better than
                          16 x 12MHz = 192 MHz!!!  And that would be if it was taking a full
                          millisec each call, and I think it is closer to half millisec,
                          which would mean close to 400 MHz.  Wheeeeeeeeeeeeee!!!!!!

                          > Whenever I get around to implementing support for various CPU and
                          > (presumably) RTC timer speeds, these values will be dynamic rather
                          > than hard-coded like they are now. 

                          Not sure what you mean here???  You mean the PC's cpu, right???
                          But what RTC?????  Oh, you mean setting the mailstation to diff
                          cpu speeds, right?  And likewise with mailstation rtc.  You
                          want it to adjust emulatin speed based on port 0d & 2f.

                          > I'd rather know more about the
                          > I/O port functionality for setting these speeds beforehand, but I
                          > haven't gotten around to tinkering on the hardware again yet either.

                          All I know are the 8/10/12 MHz speeds.  There might be more.

                          I was wondering if you ever tested the various interrupts, to
                          figure out if they were INT's or NMI's?
                           
                          > > I made all 5 of your color modes into various off-white tinted
                          > > backgrounds with black foreground,
                          > > and added a sixth choice, with bluish
                          > > foreground, and same green tinted background (ala earthlink
                          > > version of 120 & 150).
                          > >
                          >
                          > I'd be curious to see your color schemes, if you want to take screencaps
                          > or whatever.  I've never even seen the screen to any other model than the
                          > one I have.

                          I uploaded some screenshots to the root level of group site.  I
                          am gonna try to embed them at top of this post, but if it
                          doesn't work, you can see them there. 

                          > One of the next features I want to implement is a configuration file,
                          > where people can just setup the keyboard/colors/etc from there instead
                          > of needing to recompile it.

                          Config file would be great!

                          I was thinking that rather than having several canned colors,
                          it would be easier to tweak if you could adjust the rgb values
                          of current color.  Use ctrl-1, ctrl-2, & ctrl-3 for inc red,
                          inc green, & inc blue.  Use ctrl-sh-1 (2, & 3) for decrement.
                          And then save the one you like in the config file.  Or better,
                          ctrl 1, 2, 3 for inc, and ctrl q, w, e for dec.

                          CJ




                        Your message has been successfully submitted and would be delivered to recipients shortly.