IntyBASIC SDK and Windows 7 problem

[artrag]

There is a strange problem on windows 7 and the sdk.

Once installed it works perfectly until I reboot the pc

After reset, all commands seems inactive and the files in the examples and in other directories appear locked or not modifiable.

What could be the cause? If I reinstall the sdk all starts working again until the next reset.

[+DZ-Jay]

There is a strange problem on windows 7 and the sdk.

Once installed it works perfectly until I reboot the pc

After reset, all commands seems inactive and the files in the examples and in other directories appear locked or not modifiable.

What could be the cause? If I reinstall the sdk all starts working again until the next reset.

 

Hi artrag,

 

Could you give me more details of the problem? I build and test the SDK distribution and if there is a problem I want to make sure we fix it.

 

You say you install the SDK and it works, then you restart your PC and it doesn't? What do you mean "seems inactive" and "appear locked or not modifiable"? Do you mean that the directories are "read-only" and you can create new projects? Do you get any error messages at all?

 

-dZ.

[artrag]

Tonight at home I'll be able to repeat the tests and tell you more

[artrag]

I confirm the problem.

After a reset, all the .bat files in the SDK give the error "Accesso negato", like they were restricted in some way. I cannot figure why, the user used to install the SDK has administrative powers and rebooting I use the same user used to install the SDK.

If I reinstall the SDK the problem disappear and I can work as long as I do not turn off the PC or reset it. At the following restart of the PC the problem with "Accesso negato" appears again.

[+DZ-Jay]

OK, that's strange. You said that you are using Windows 7, right? Are you installing the SDK in the default directory?

 

I don't have Windows 7 at hand, but I'll seek to test this. I am currently working on the next version of the SDK (and a Mac OSX edition as well), so I want to make sure to resolve all these issues.

 

By the way, if you type "set" from the command line, can you post here the values for the following variables?

• INTYBASIC_INSTALL
• PATH

Feel free to provide any other details you think may be helpful.

[freewheel]

My Italian is very, VERY limited. But I believe that it's telling you "Access Denied", Windows' way of saying the user doesn't have permissions on the file(s).

 

I'd check the permissions on the .bat files in question - before and after the reboot - and make sure the user ID actually has read and execute permission on them. Also check the folder than it's getting installed into. Windows does strange things like this, where you have permission one moment and not the next - and reboots are generally the most "destructive" action you can take in terms of your operating environment. I'm used to running as a full-blown admin all the time, so the only time I see this is if it's protected Windows files. And there's no way to get the SDK installed with that kind of setup.

 

The permissions must be changing after the reboot, or you're not quite using the same user environment. I have no idea why, but I've seen weirder.

 

My Windows 7 sets the files up exactly as I'd expect. It gives full access to the user who installed the SDK, as well as any Administrator. And it persists through a reboot. If I had to guess, I'd wonder if the user ID you are using is actually an Administrator. Because an admin should be able to read any file from any folder, regardless of anything else.

[+DZ-Jay]

My Italian is very, VERY limited. But I believe that it's telling you "Access Denied", Windows' way of saying the user doesn't have permissions on the file(s).

 

I'd check the permissions on the .bat files in question - before and after the reboot - and make sure the user ID actually has read and execute permission on them. Also check the folder than it's getting installed into. Windows does strange things like this, where you have permission one moment and not the next - and reboots are generally the most "destructive" action you can take in terms of your operating environment. I'm used to running as a full-blown admin all the time, so the only time I see this is if it's protected Windows files. And there's no way to get the SDK installed with that kind of setup.

 

The permissions must be changing after the reboot, or you're not quite using the same user environment. I have no idea why, but I've seen weirder.

 

My Windows 7 sets the files up exactly as I'd expect. It gives full access to the user who installed the SDK, as well as any Administrator. And it persists through a reboot. If I had to guess, I'd wonder if the user ID you are using is actually an Administrator. Because an admin should be able to read any file from any folder, regardless of anything else.

 

The SDK installs on the user's "Documents" folder by default. The only thing I can imagine is that he installs it as "administrator" and then logs in with his own user account.

[artrag]

Same user with administrative rights. It happens only on my home pc (windows 7 home premium).

On my laptop (windows 7 professional) I have no problem

[freewheel]

I wouldn't be surprised if Windows 7 "home" has a screwy admin privilege setup. Even in the enterprise versions of Windows, "admin" never has complete rights on a system. Microsoft tends to over-protect users - generally a good thing, but sometimes they go overboard.

 

My laptop is 7 home premium and I don't have this issue with the SDK.

 

Edit: as I actually test things to see if they work, I notice that the .bat files do the "pop up the window and disappear" thing that non-command line users complain about with IntyBASIC and jzintv. I thought the whole point of the SDK was to work around that little Windows-ism (well, a good chunk of the point anyway). I know there's a way to keep a command prompt window open, I just forget how.

 

And no, I haven't exactly read the manual I just kinda assumed these would pop up a command window and either ask for input (ex: a project name) or at least stay up so the user knows what the error was.

 

I'm definitely not getting permissions errors though.

[CrazyBoss]

btw what is the max size of the compiled rom ? - 16k = 16384bytes ?

[GroovyBee]

btw what is the max size of the compiled rom ? - 16k = 16384bytes ?

You are allowed to use the "asm org $XXXX" statement in your game, so the maximum size becomes 42K words or 84K bytes.

 

Edit: I forgot to mention that you'll have to persuade IntyBASIC to map out the ECS ROMs to use the 42K memory map. That can be done with the sound command or by using cont3/4.

Edited August 19, 2015 by GroovyBee

[+DZ-Jay]

I wouldn't be surprised if Windows 7 "home" has a screwy admin privilege setup. Even in the enterprise versions of Windows, "admin" never has complete rights on a system. Microsoft tends to over-protect users - generally a good thing, but sometimes they go overboard.

 

My laptop is 7 home premium and I don't have this issue with the SDK.

 

Edit: as I actually test things to see if they work, I notice that the .bat files do the "pop up the window and disappear" thing that non-command line users complain about with IntyBASIC and jzintv. I thought the whole point of the SDK was to work around that little Windows-ism (well, a good chunk of the point anyway). I know there's a way to keep a command prompt window open, I just forget how.

 

And no, I haven't exactly read the manual I just kinda assumed these would pop up a command window and either ask for input (ex: a project name) or at least stay up so the user knows what the error was.

 

I'm definitely not getting permissions errors though.

The SDK offers command-line utilities, and they are to be used from the command console. The manual describes how to do this, and the SDK installs a handy shortcut that opens directly in the SDK folder.

 

Double-clicking the batch files won't do anything, except that annoying pop-up thing you mentioned.

 

An IDE is part of the future strategy, but at the moment programmers are expected to use the command console.

 

What the SDK simplifies is the incantations needed to call the compiler, assembler, and emulator/debugger. It also provides other useful utilities, tutorials, and lots of examples.

 

And finally, it sets up the environment and organizes the workspace in a very convenient manner so that users can manage their projects easily.

[+DZ-Jay]

btw what is the max size of the compiled rom ? - 16k = 16384bytes ?

The "K" when talking about Intellivision ROMs represents "Kilo-words" (or DECLEs, in tha parlance of the platform. These are 16-bit words, or two-bytes each.

 

If the maximum ROM memory map supports about 42K words (without paging), that'll be about 84KB.

 

dZ.

[CrazyBoss]

 

Ok, I was just worried if the rom file is larger than 16,384 bytes (reported by the windows) using the DIR command, it can still be

transfered to a flash cartrigde and be played on a real Intellivision.

[GroovyBee]

Ok, I was just worried if the rom file is larger than 16,384 bytes (reported by the windows) using the DIR command, it can still be

transfered to a flash cartrigde and be played on a real Intellivision.

I'd recommend creating a *.rom file because that kid of file has all the memory layout information contained in one place. If you are using cart RAM you'll have problems with the Bliss and Nostalgia emulators. They are both quite old now and don't seem to support it.

[freewheel]

Ok, I was just worried if the rom file is larger than 16,384 bytes (reported by the windows) using the DIR command, it can still be

transfered to a flash cartrigde and be played on a real Intellivision.

 

If it can be played in an emulator, it can be played on a flash cart (the newer ones, anyway).

 

You'll notice what happens when you make a file that is "too big" within the emulator itself - a nice black screen usually. And you can get around that, up to the 42K word (84KB) limit people are talking about here.

[freewheel]

Edit: I forgot to mention that you'll have to persuade IntyBASIC to map out the ECS ROMs to use the 42K memory map. That can be done with the sound command or by using cont3/4.

 

I haven't actually hit this yet - is this decently documented? I know conceptually what you're talking about, but I kinda assumed that if you start using ECS functionality, it would map things IN, not OUT.

[GroovyBee]

I haven't actually hit this yet - is this decently documented? I know conceptually what you're talking about, but I kinda assumed that if you start using ECS functionality, it would map things IN, not OUT.

To use the 42K memory map you want to use the space at $2xxx, $7xxx and $Exxx for your game's code/data. However, all of these memory segments are where the ECS has ROMs mapped too. In order to prevent a conflict with your code you need to map out the ECS ROMs. This is done automagically for you in IntyBASIC by using cont3/4 or by using "sound 5,0". If you are using the larger memory map for your game I'd recommend adding "--ecs=1" to the jzintv command line.

[artrag]

The sdk problem seems solved in this way:

I installed the sdk after having removed it (working), saved all files in a new directory, rebooted (all commands stopped working) and copied back all the saved files in the installed files.

Now all works even across reboots

[+DZ-Jay]

The sdk problem seems solved in this way:

I installed the sdk after having removed it (working), saved all files in a new directory, rebooted (all commands stopped working) and copied back all the saved files in the installed files.

Now all works even across reboots

 

That is... just... bizarre!!!

 

I think Tarzilla may be on to something here. He performed some tests on one of his installations of Windows 7 and noticed that his profile directory was being mapped to a network drive. He encountered a similarly strange problem.

 

My guess is that whatever functionality the SDK installer uses to create folders and copy files, fails to include some special security attribute needed by Windows 7. Copying the folders manually later on using the Windows Explorer apparently does. Very strange.

 

Thanks for following up on this, and I am glad it worked out. By the way, the next version of the SDK (coming Any Day Now, I swear!) will allow you to select your own installation folder, so perhaps that's the secret to avoiding this issue.

 

In any case, one of the "features" of the SDK is that uninstalling it does not touch the "Projects" folder in any way, so that the user's programs are kept safe and intact.

 

-dZ.