blueMSXnano 0.9

by dvik on 06-08-2009, 01:46
Topic: Emulation
Languages:

This year has been an interesting year for emulator fans. Many MSX emulators for different host computers have seen the light. Today Daniel Vik released a new text only MSX1 emulator that runs in a DOS shell. The emulator is intended to support enough hardware emulation to run MSX basic in a DOS shell. The emulator runs the Z80 as fast as possible while keeping a frame rate of 50Hz. The release includes a binary and source code.

Relevant link: blueMSXnano download

Comments (78)

By only_69

Hero (565)

only_69's picture

06-08-2009, 03:06

The link is wrong ... Crying

By dvik

Prophet (2200)

dvik's picture

06-08-2009, 04:41

Fixed. I replaced the file on the webserver and it changed case. Now you can enjoy MSX in a console window Smile

By Vampier

Prophet (2397)

Vampier's picture

06-08-2009, 07:08

LOL Smile it's cool!

By dvik

Prophet (2200)

dvik's picture

06-08-2009, 08:41

I just added a few new features. Still same download link.

* Support for normal execution speed
* Support for cursor keys
* Clear screen before starting
* Fixed bug in memory mapper

These fixes and enhancements makes it possible to play great msxdev'08 games, such as PWND. Enjoy!

By cax

Prophet (3738)

cax's picture

06-08-2009, 09:14

Erm.. what's the point in text-only emulator ?
To run it on PC XT ?
To make the smallest emulator available ?
To participate in that now fashionable crap contest ?

By pitpan

Prophet (3152)

pitpan's picture

06-08-2009, 11:27

Interesting project, although it is indeed a text-only MSX-BASIC emulator. But it could also help for testing easily the Professional Adventure Writer (PAW) for MSX. I need to finish that project!

By Vampier

Prophet (2397)

Vampier's picture

06-08-2009, 16:19

I read the source code and I'm now understanding how things are emulated.

By muffie

Paladin (933)

muffie's picture

06-08-2009, 16:44

Is it possible to run Bussas Quest?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

06-08-2009, 17:54

> To run it on PC XT ?

No, this program does not run in DOS Crying

By dvik

Prophet (2200)

dvik's picture

06-08-2009, 18:07

I think it does if you recompile it. I may have thrown in a few optimizations that aren't that good and two of the architecture specific methods use Windows API. It should be pretty easy to do a full dos port, but I need to do more research to find the dos equivalent api for e.g. set cursor position and delay.

What the port does now is running in a windows command shell which is a bit different from DOS indeed.

By dvik

Prophet (2200)

dvik's picture

06-08-2009, 18:51

Another small update:

* Full support for slots
* Support for running 48kB roms
* Extended RAM to 64kB

So now all msxdev'08 games run fine.

So fans of "Hose Diogo Martinez: The Bussas Quest" now have another great emulator in which they can play their favorite game Smile

If someone is good at DOS, it would be fun to get a port of the emulator so NYYRIKKI can run it on his old PC. Its only a couple of methods that needs to be ported so it shouldn't be very hard.

By ARTRAG

Enlighted (6845)

ARTRAG's picture

06-08-2009, 19:36

You support only screen 0, which msxdev08 game can run?

[edit]
Maybe DD could be playable as it does not use sprites

By Sd-Snatcher

Hero (582)

Sd-Snatcher's picture

06-08-2009, 19:41

Now you can access IRC chanel from your pc using msx software Tongue

By dvik

Prophet (2200)

dvik's picture

06-08-2009, 19:47

It does screen 0, 1, and 2. But only the bgmap part. So graphical games may not look as expected. DD runs but its a bit hard to play.

By jr

Champion (377)

jr's picture

06-08-2009, 21:47

Porting the win32 functions to dos shouldn't be that big of a problem; another thing to consider would be that I suppose most if not all dos c compilers lack a 64bit integer data type. However it seems you aren't using it very much so perhaps it could be replaced with a double in the dos port?

By dvik

Prophet (2200)

dvik's picture

06-08-2009, 22:06

For a true DOS port, there are a few things that could be modified a bit. The 64 bit type is only used in frequency conversions and can be done differently and I think that is something I should fix. I only used 64 bit type because I was lazy Wink

The other thing that can be made differently for a DOS port (at least for old computers) is the bgmap rendering. Now its recalculating the entire screen each frame, diff it against previous screen and redraws if its been modified. This is nice and cheap on a modern PC (mainly reduces flicker), but may be unnecessary in a pure DOS port. Another reason is that the emulator was initially made to overclock the Z80 as much as possible, so with a z80 running at 100+x speed, its pretty efficient to fully redraw on each frame.

By jr

Champion (377)

jr's picture

06-08-2009, 22:40

Sure, but first step is a first step. It seems I was too hasty to judge the dos compilers, the code compiles almost fine with open watcom c compiler for dos since it does indeed support the long long type. I had to do some tweaks in z80.c and bluemsxnano.c though to get rid of compilation warnings and errors because you seemed to assume at some places that int is 32bit, which it is not for a true 16bit dos executable.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

06-08-2009, 23:34

First things first, but I can't help my self thinking that maybe in future this could be turned into something similar as MSX-DOS Emulator.

I know this requires making support for BDOS function translations etc, but maybe it could be then used to run also MSX-DOS2 programs from DOS prompt... Unfortunately the current version of MSX-DOS emulator is limited to running CP/M & MSX-DOS1 programs and does not support MSX-BIOS at all... How ever it is very handy tool and I would like to see advanced version this idea some day...

By muffie

Paladin (933)

muffie's picture

07-08-2009, 04:10

screen 2 support? I tried:
10 screen 2
20 circle (128,96),10,10
30 goto 30

and... nothing.

By pitpan

Prophet (3152)

pitpan's picture

07-08-2009, 10:06

muffie: SC2 is indeed supported, but only name table is rendered and without allowing modifications to pattern table and colour table. Therefore, your circle in pure SC2 would be rendered as ASCII characters copied three times in screen. Indeed, any SC2 screen without "VPOKing" the name table would be the same Wink

By jr

Champion (377)

jr's picture

07-08-2009, 13:33

I noticed you simply call printf to display the "framebuffer". I guess that should be changed to printf("%s", ...) if you want to avoid phunney effects like see what happens when you enter "%s" without quotes in the MSX screen...

By boblet

Master (187)

boblet's picture

07-08-2009, 14:44

actually this might be reasonably useful if it runs in a pure dos environment and has access to the serial and par ports etc

and yes we could use quickbasic etc but this emu seems quite interesting.

By dvik

Prophet (2200)

dvik's picture

07-08-2009, 16:24

@Jr, Yeah I didn't think of the quotes, I'll change the printf statement. Did you have any other changes as well?

By pitpan

Prophet (3152)

pitpan's picture

07-08-2009, 21:50

Apparently blueMSXnano does not like wine under Linux Sad

By dvik

Prophet (2200)

dvik's picture

08-08-2009, 17:12

It looks like wine don't handle some console commands correctly. For me the emulator starts up in Linux, but it neither do 'set position' nor keyboard input. I think you need to wait for the linux port of the emulator.

By karloch

Prophet (2157)

karloch's picture

08-08-2009, 18:19

what about openMSX ncurses renderer?

By dvik

Prophet (2200)

dvik's picture

09-08-2009, 07:20

Another update:

* Added Linux port. Developed by wouter_
* Minor fixes

Note that the linux version is only distributed in source code, but it should be trivial to build the emulator using wouter_'s Makefile.

I also uploaded the source code to sourceforge: http://bluemsx.svn.sourceforge.net/viewvc/bluemsx/trunk/blueMSXnano/ If anyone is interested in modifying the code (e.g. jr), let me know and I'll give you the privileges you need.

By jr

Champion (377)

jr's picture

10-08-2009, 14:43

Yes I made quite many changes to get it running under plain DOS with a 8086. There is some problem left still, as MSX BASIC simply replies with "Out of memory" for just about any statement that would require storing something in the memory so perhaps some memory mapping related issue...

By dvik

Prophet (2200)

dvik's picture

10-08-2009, 17:52

jr, If you want access to the SVN archive, let me know what your sourceforge user name is and I'll give you the right permissions.

By jr

Champion (377)

jr's picture

10-08-2009, 20:21

errr... ok I created an account, jr777, not sure if I master how sourceforge works though Wink

By dvik

Prophet (2200)

dvik's picture

10-08-2009, 21:02

You are added to the project. To get and to modify the source code you need a SVN client. I use TortoiseSVN for Windows and it works very well but there are other clients too. Once you have your SVN client, you need to get the source code, check the SVN documentation in one of the sub menus of sourceforge. Its pretty easy to set up.

By dvik

Prophet (2200)

dvik's picture

11-08-2009, 01:26

I should say too jr, that if you want to share your updates and don't want to deal with sourceforge you can send me a patch and I'll do the updates. But if you want to learn sourceforge, I guess this is a good opportunity since its a small project.

By jr

Champion (377)

jr's picture

11-08-2009, 17:06

I got it fully working but I suppose I have made a lot of seemingly meaningless changes in the source to keep the dos compiler (and me) happy... do you want all of that in the sourceforge repository as well? Right now I'm not particularly in the mood for minimizing the delta... I checked that the linux port still compiles and works on my osx machine at least but I have not tried what the windows port likes about the changes I've made.

By dvik

Prophet (2200)

dvik's picture

11-08-2009, 17:35

put it all in. I'll compile the windows version and fix any issues if there are any. If you want, you can either post a link to the dos version here or I could package it up. I'm looking forward to try it.

By jr

Champion (377)

jr's picture

11-08-2009, 22:05

okay I just committed the changes, I hope - I made a batch file that acts as a makefile since the real makefile was already taken for the linux port. I had to use a wildcard to catch bluemsxnano.c since real DOS only has the classic 8+3 filenames. I think a lot of things would need optimizing to make it really run fast enough on an old, slow PC - now I just replaced the rendering printf with an assembly routine. I've also included the DOS binary I built, named bluenano.exe so it fits 8+3 and doesn't collide with the Windows executable. I suppose the DOS port will only compile with the watcom c compiler because I resorted to using a couple of compiler specifics.

By dvik

Prophet (2200)

dvik's picture

12-08-2009, 06:06

Great job jr. I added the MS-DOS build and updated source code to the download zip. So now you can download and try the new DOS version.

By dvik

Prophet (2200)

dvik's picture

12-08-2009, 06:14

I tested the Dos emulator in DosBox and had some problem with the emulation speed. It does work, but runs extremely slow. CPU frequency shows 0 MHz. I don't use Dosbox that much though so I don't know if its some setup problem perhaps. It looks very cool though Smile

By jr

Champion (377)

jr's picture

12-08-2009, 07:43

Yep.. on my machine under vmware it runs faster than normal msx speed but not very fast, perhaps double speed or something. The CPU frequency display is broken because the printf format string uses %d to display the number but the value is a 32bit integer so in dos that should be %ld or even %lu since it is unsigned. So it usually always shows only zero because the high order word of the value is zero.

Some stuff like the display update could be made several times faster by abandoning the use of system BIOS routines in favor of direct display memory access -- I could change that since the code anyway only runs on CGA or higher already (it could be made to run on MDA but I didn't bother, perhaps I should?). I guess overall the code would benefit if it would be compiled for a better CPU than 8086. Also I didn't check what the code generated by the compiler looks like; whether all necessary functions are inlined etc.

About dosbox, I think it has it's own speed limiter which you can alter. So it may be that by default your dosbox is limiting the emulated machine speed to something less than the maximum your PC could do.

By dvik

Prophet (2200)

dvik's picture

12-08-2009, 08:00

the dosbox had indeed a cycle (or instruction) counter that was set to 3MHz. I increased it to 25MHz and then it worked fine. Pretty cool though, running an emulator in an emulator.

By jr

Champion (377)

jr's picture

12-08-2009, 12:23

just updated the dos port so that it tries to auto-detect and support monochrome display adapters as well (mda, hercules, monochrome ega/vga) and made it use white text on blue background color when operating on a color display adapter so you get the familiar default MSX BASIC colors eventhough colors are not otherwise rendered. I think it should now run on just about any PC you can find... well, it does require over 128K free RAM so I think PC's with less than 256K RAM will not run it.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

12-08-2009, 13:57

I think I have to dig up my trusty old Nokia 9110 and try to run this on it... It has 33MHz 386SX and a bit stripped down BIOS that is anyway good enough to run DOS. Smile

Now when dvik already tested this on 3MHz, maybe you should compile this for MSX. Tongue

By jr

Champion (377)

jr's picture

12-08-2009, 14:03

yeah somebody should port this to msx-dos... and after that if disk support would be added to this you could really proof the concept by running the msx-dos port of the emulator inside the emulator itself Wink

the ms-dos port should run on a 4,77MHz PC if the machine just has enough RAM however I would imagine it emulating the 3.57MHz Z80 probably couldn't reach very high speeds...

By Manuel

Ascended (18861)

Manuel's picture

12-08-2009, 22:24

Great collaboration guys!

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

13-08-2009, 21:12

I tried this with my Nokia 9110 and got it almost working... First the screen was tolly messed up (mostly just black) but when I replaced all #CD #10 with HEX editor to #90 #90 (INT 10 -> NOP) I managed to actually see almost the MSX screen. (Something like text in every other character)

Is there a way to force this DOS port to use only character output without any direct access or display mode changes? ... I mean same way as the Windows version works?

If I have understood correctly the problem is that this device does not really have text mode but more like MSX SCREEN 5 graphic mode (16 shades of gray) and pure B/W mode. All the character output emulation is done on BIOS. Theoretically the display adapter should be able to emulate CGA/EGA but it does not work correctly propably because the device has so weird shape LCD panel (640x200)

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

13-08-2009, 22:42

Actually you can forget this...

I found your prebuild (1146) and did similar hacking to that. Now I have working MSX-emulator also for Nokia 9110 Cool

Running Naked in a Field of Flowers

By gargamel

Expert (101)

gargamel's picture

13-08-2009, 23:09

Perhaps also blue and white colors for the Windows port?

void clearscreen(void)
{
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), 0);
system("cls");
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), 15 + (9 * 16));
}

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

14-08-2009, 00:48

By jr

Champion (377)

jr's picture

14-08-2009, 08:20

Nice work =) The previous version of the dos port is indeed probably easier to make to work as it uses BIOS services to display the characters on the screen. The latest dos port writes directly to display memory, which is much faster. On the 9110 the display memory happens to be located at the correct address but as you said, it has no text display mode and thus the data written to the display memory by the emulator is not displayed correctly because the values are interpreted as a bitmap rather than character+attribute values. On the other hand, the 9110 could run a binary optimized for 80386 rather than 8086 and get some speed boost (I wonder if it could in fact run a protected mode executable via DOS/4GW).

By dvik

Prophet (2200)

dvik's picture

14-08-2009, 15:33

Very cool indeed NYYRIKKI Smile There are also some other optimizations that can be made in the z80 core. I can try to do some of the ones I have in mind.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

14-08-2009, 18:28

Well... maybe it would be better idea to compile the code with correct parameters than trying to fry the battery & CPU Tongue How ever using C-compilers is way too complicated for my brains, so I'm stuck with binary patching and writing DOS driver TSR's with assembler...

By jr

Champion (377)

jr's picture

16-08-2009, 07:05

NYYRIKKI, can you tell me what patches you did exactly? Did you just remove the call that tries to switch to text mode or something else as well? I could add a command line switch for the dos-port to run it in the 9110 with the modifications included.

By dvik

Prophet (2200)

dvik's picture

16-08-2009, 09:50

I made a few optimizations that doubles the z80 speed on a 32 bit processor. Not sure how much it improves a 16 bit machine, but it should at least be a bit faster I think. Hopefully enough to run pwnd in full speed on NYYRIKKI's Nokia 9110.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

16-08-2009, 12:46

Yes, removing mode change is enough.

Oh BTW I said earlier that this device has 386 SX, but in fact it is 486 SX... Running in protected mode should not be a problem.

By jr

Champion (377)

jr's picture

17-08-2009, 10:35

Ok - just a thought because in a protected mode binary the emulator could take full advantage of 32bit registers and linear memory.

Nevertheless, I improved the ms-dos port so that it accepts a "-nodirect" command line option. The new option will prevent the emulator from changing display modes, assumes a monochrome display and will use the pc bios services to display the characters so it should work on the 9110 out of the box. If you're not too afraid to install the watcom c compiler you can easily compile a 486-optimized binary yourself by replacing the "-0" option with a "-4" option in the dosmake.bat script... or alternatively, I can also mail you the 486 binary directly.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

17-08-2009, 23:40

Well... At least I tried... Smile

Z80.C(191): Warning! W135: Shift amount too large
Z80.C(215): Warning! W135: Shift amount too large
Z80.C(245): Warning! W135: Shift amount too large
Error: Compiler returned a bad status compiling "Z80.C"

By dvik

Prophet (2200)

dvik's picture

18-08-2009, 00:05

Are you compiling for DOS, Linux, or Win32?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

18-08-2009, 00:07

I'm trying to compile with DOSMAKE.BAT

By jr

Champion (377)

jr's picture

18-08-2009, 07:19

Odd... are you sure you are trying to compile the latest sources? Looks like the messages you would get with older versions of z80.c file. I'm using open watcom 1.8, no errors, no warnings.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

18-08-2009, 08:56

I downloaded open-watcom-c-win32-1.8.exe and I'm trying to compile revision: 1159 of Z80.c

These are the problematic lines, it points to:

    z80.regs.AF.B.l = (UInt8)((z80.regs.AF.B.l & (S_FLAG | Z_FLAG | V_FLAG)) |
        (((*reg1 ^ reg2 ^ rv) >> 8) & H_FLAG) |
        ((rv >> 16) & C_FLAG) |
        ((rv >> 8) & (X_FLAG | Y_FLAG)));

    z80.regs.AF.B.l = (UInt8)((((z80.regs.HL.W ^ reg ^ rv) >> 8) & H_FLAG) | 
        ((rv >> 16) & C_FLAG) | ((rv & 0xffff) ? 0 : Z_FLAG) |
        ((((reg ^ z80.regs.HL.W ^ 0x8000) & (reg ^ rv)) >> 13) & V_FLAG) |
        ((rv >> 8) & (S_FLAG | X_FLAG | Y_FLAG)));

    z80.regs.AF.B.l = (UInt8)((((regVal ^ reg ^ rv) >> 8) & H_FLAG) | N_FLAG |
        ((rv >> 16) & C_FLAG) | ((rv & 0xffff) ? 0 : Z_FLAG) | 
        ((((reg ^ regVal) & (regVal ^ rv)) >> 13) & V_FLAG) |
        ((rv >> 8) & (S_FLAG | X_FLAG | Y_FLAG)));

By jr

Champion (377)

jr's picture

18-08-2009, 11:19

Ah, the problem is you're trying to compile for win32, not dos. I use the native dos version of the compiler so it will by default use dos target whereas you are using the win32 version which defaults to win32 target. Add "-bcl=dos" option to the command in dosmake.bat that runs the compiler&linker. Also make sure you have dos target support installed with the compiler Wink

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

18-08-2009, 21:06

Thanks, adding this parameter did the trick. LOL! This latest version is actually second MSX emulator that you translated specially for my phone so I think I really need to buy you few beers when we meet next time. Tongue (Earlyer jr converted fMSX to 9210, because I asked so many times Eek!)

How ever it seems that dvik's optimizations or compiling to 486 did not make any visible change to speed... It seems all of the time is used to draw the screen...

I now however removed the cursor draw routine I used earlyer and it helped finally to get some more speed.

New video is here:
http://www.youtube.com/watch?v=wCB2NL2GVwc

By dvik

Prophet (2200)

dvik's picture

18-08-2009, 21:33

For your particular device the screen updates can be improved a lot. The original nano was intended for running the Z80 very fast, but on a slow device as the 9110, I can make something different and you should be able to get much better performance, I'll see what I can do. Btw, these tools you're using are they freely available?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

18-08-2009, 22:02

Tools?

Only tools I've used so far is DEBUG (Is bundled also with modern Windows computers) and A86 assembler (free) together with some example sources...

If you mean that cursor TSR or crashing the phone to DOS, check here:
http://www.geocities.com/lucassioli/dos9k/projects.html

I can also send you my Finnish keyboard driver source that I've extended to handle backlight and trapping not supported BIOS calls. The trick to change CPU speed I found by reading ElanSC400 chip control registers descriptions.

I have not found more than two useful display modes from this device. One is 1 bit linear 640x200 (The one used now) and other is 4bit linear 640x200 mode.

ElanSC400 should support also CGA and MDA emulation, but so far I have not managed to adjust the output correctly... So far it seems that it expects 320pix wide screen or something... (Visually best what I've managed to get is that CGA games run splitted to 4 screens)

By jr

Champion (377)

jr's picture

19-08-2009, 17:08

NYYRIKKI, I'll try to hold you to that promise... you wouldn't happen to have any other gadgets that still aren't able to run MSX software? lol

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

19-08-2009, 21:53

Hmm... I don't have MP3 players or game consoles and now I think all my phones and computers can run MSX software... Actually even my new digital TV-receiver can run MSX software, so I think you can get a rest for a while. Cool Eek!

Oh BTW it seems that running BlueMSX nano on 100MHz 9110 is not going to be that easy... -> http://msx.fi/temp/fail.jpg ._,

By dvik

Prophet (2200)

dvik's picture

19-08-2009, 21:57

I'll try to change the screen update to be more efficient on slow devices.

By dvik

Prophet (2200)

dvik's picture

20-08-2009, 04:35

I added a dirty flag on vram and I added frameskip, so you can see if it makes things run a bit faster.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

20-08-2009, 09:19

It doesn't help unless the display routines are updated as well... I actually tested the new code and it seems to me that the emulator runs in same speed on 33MHz and 66MHz. Smile2 I think you get the idea, if you think the display as 9600bps VT100 display. It is not that bad, but close. Tongue

By jr

Champion (377)

jr's picture

20-08-2009, 12:26

Yep, well, there is no telling what the firmware does when receiving the bios service requests for moving the text mode cursor and displaying a character. It would of course be at least a little bit faster to simply draw the character bitmaps in the emulator rather than ask the bios to do it -- in fact I suppose you could use the character pattern data from the msx vram so you would get authentic look&feel. After a quick look at the sc400 reference manual, it seems one should be able to run the display controller also in text mode which would give a significant speed boost (you would only need to transfer 1/8 of the data).

Your observation about the emulation running at the same speed whether the cpu core is running at 33mhz or 66mhz could be explained by the display controller being accessed externally over a bus which is always running at the same speed regardless of the core cpu speed. When the display routine becomes the bottleneck it will not help you much to make the cpu run faster -- it will still take the same amount of time to transfer the same amount of data from the cpu to the display. I think that is what is happening here. If this is true, then the only way to speed things up is to reduce the amount of data transferred from the cpu to the display.

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

20-08-2009, 19:36

Yes, I have a feeling that the display controller is connected (internally) trough 8MHz ISA bus. Smile2

I'm well aware that the Elan SC400 should be able to enter fully CGA compatible mode, but I have just not managed to get any CGA mode working properly... Maybe it is because games use BIOS to change screenmode and that is not CGA compatible... Or maybe I have just not found correct values to setup the adapter.

10 years ago I started testing, but I stopped since too many times I ended up with black line in middle of screen and LCD making "funny" noices... I just didn't want to burn the display since this phone was new back then. Smile

I think now it is good time to start experimenting again... I have actually even few spare ones to break...

By jr

Champion (377)

jr's picture

21-08-2009, 12:06

fwiw, I did small mods to the linux port to make it work on solaris; I only had to work around not having FIONREAD ioctl -- oddly enough, there is FIORDCHK which could have been used instead but at least on my solaris box that ioctl request fails on stdio.

By dvik

Prophet (2200)

dvik's picture

24-08-2009, 19:55

@NYYRIKKI: What command line options are you using when running the emulator on the Nokia ?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

25-08-2009, 02:10

@dvik: -nodirect -s msx.rom -b pwnd.rom

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

25-08-2009, 02:25

... If you are wondering the borders, that is just external bitmap loader + "SET SCROLL" type of registry change in BAT-file... Eek!

The executable has not been changed at all.

By dvik

Prophet (2200)

dvik's picture

25-08-2009, 07:37

I just wanted to see that you didn't use the -n flag which limits the z80 speed. I'm a bit puzzled that the changes I made didn't have any effect on the performance. I updated the emulator to only redraw the screen every 4th frame instead of every frame. So if it was a bus issue, it would improve with frameskip, right?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

25-08-2009, 15:33

Actually when I use the "-n" parameter I can see some frame skipping, but the speed is still about the same Question

Maybe memory bus?

By dvik

Prophet (2200)

dvik's picture

25-08-2009, 17:44

What type of memory does the Nokia use and how is it hooked up and how wide is the data bus?

By NYYRIKKI

Enlighted (5939)

NYYRIKKI's picture

25-08-2009, 18:46

It is using 60ns EDO DRAM 16bit wide data- and 12bit wide address bus, no wait states.

For more details about the hardware check out for example:
http://www.eserviceinfo.com/downloadsm/5435/Nokia_9110.html
http://www.amd.com/epd/processors/4.32bitcont/13.lan4xxfam/22.lansc400/index.html