TriloTracker beta thread.

Page 41/48
34 | 35 | 36 | 37 | 38 | 39 | 40 | | 42 | 43 | 44 | 45 | 46

By mars2000you

Enlighted (5525)

mars2000you's picture

14-03-2016, 21:36

Grauw wrote:

It’s trying to create in the Program Files directory most likely, which is the current directory in openMSX on Windows. Try to specify a full path like c:\myimage.dsk.

One good reason to never use the automatic installation of openMSX (at least under Windows).

Personally, I prefer to unzip a zipped version of openMSX and to do that directly in a subdirectory of My Docs. It has some advantages as all the openMSX related files (for example screenshots) are in the same place on the harddisk.

By Huey

Prophet (2644)

Huey's picture

14-03-2016, 21:42

After selecting a valid path the errors continue:

Couldn't create image: File "c:\image.dsk" not found.

I'm done for. I'll let it soak in a few days. Perhaps will try it later this week.

By Huey

Prophet (2644)

Huey's picture

16-03-2016, 11:55

Finally. After a lot of frustration Evil to even be able to emulate the MFRSCC+ 512 SD in openMSX. I can now reproduce the issues found. There are all sorts of strange things happening when TT runs on this configuration. I am not yet sure what is causing these problems. For now I assume it is in my own code.

I'll keep you updated.

By Huey

Prophet (2644)

Huey's picture

16-03-2016, 15:13

I've been able to solve the issue.
Somehow I needed to disable my ISR hook upon calling the MSXDOS function "GET ENVIRONMENT ITEM".
Seems only causing issues on this configuration.

Will release a fixed version soon after some more testing.

By Grauw

Ascended (8615)

Grauw's picture

16-03-2016, 16:07

Is your ISR located above C000H ? State of pages 0-2 can not be guaranteed during the ISR.

By Huey

Prophet (2644)

Huey's picture

16-03-2016, 16:13

@Grauw: You are right. ISR is in page 1.

I have released the updated version: https://github.com/cornelisser/TriloTracker/releases/tag/V0.9.1

By Manuel

Ascended (15970)

Manuel's picture

16-03-2016, 18:51

The problem with kernel.dat is that it doesn't fit on a normal diskette. So you need that IDE trick, which is complex and error prone. That's why I used the separate files, which just fit on a disk image. But I didn't know that the nextor.rom just vanished in the mean time... Luckily there's a workaround for that via archive.org, as mars mentioned.

By the way, in the openMSX console, you have to use forward slashes as path separator, so C:/myImage.dsk (if you even have permission to write on the root of the C drive). That may also have caused some of the frustration.

mars: the installer only exists for Windows (it's not necessary for other platforms). I'd definitely recommend to use it, as it's the safest way to get a normally working installation, it's very hard to make mistakes with it. Alas, apparently the working directory is not very convenient, but you shouldn't notice that very often, except with some more advanced commands like diskmanipulator. Workaround is then to indeed specify the full path for such commands, to a place where you do have write permissions. So, please don't give bad advice to not use the installer. For almost all Windows users it's definitely the best option.

By Grauw

Ascended (8615)

Grauw's picture

16-03-2016, 19:01

Maybe the working directory should be changed to the user directory, my documents or simply the root in the installer or the application... Writing to Program Files on Windows is not done since... Windows 98?

By ssfony

Expert (66)

ssfony's picture

16-03-2016, 20:15

@Huey: you did it!!! No more crashes on F10 Smile
Very cool, thanks, and pretty good that you found the bug so fast.

By Manuel

Ascended (15970)

Manuel's picture

16-03-2016, 22:15

Grauw, the CWD isn't Program Files by design. It's just that no one ever came up with this problem and we never thought about it either. The CWD isn't touched at all by openMSX. So it is what it is.

Page 41/48
34 | 35 | 36 | 37 | 38 | 39 | 40 | | 42 | 43 | 44 | 45 | 46