IntyBASIC no ECS?

[First Spear]

Can anyone name a reason I should not have ECS compatibility? Are there more memory regions I should ASM ORG around to prevent crashes?

 

Thanks.

[intvnut]

Compatibility with the ECS mainly means page-flipping the ECS ROMs out of the address map so that you can use those address ranges yourself. If you're using a cartridge that supports Mattel-style page flipping, you can simultaneously flip the ECS out while flipping your own game in, even if you don't do any page flipping while the game's running.

 

What I'd recommend is adding a bit of ASM at $4800 to perform the necessary page flips, and tweak your ASM ORG statement for code at $7xxx and $2xxx to put it in, say, page 2. Something like:

.

   ' Disable ECS ROMs
   ASM ORG  $4800
   ASM MVII #$2A52, R0
   ASM MVO  R0, $2FFF
   ASM MVII #$7A52, R0
   ASM MVO  R0, $7FFF
   ASM MVII #$EA52, R0
   ASM MVO  R0, $EFFF
   ASM B    $1041

.

And then elsewhere, instead of saying ASM ORG $7000, say ASM ORG $7000:2. Likewise for ASM ORG $2000 becoming ASM ORG $2000:2.

 

Note that you don't need to do the same for the ROM at $E000, as the ECS early boot sequence never touches that ROM. The code at $4800 should run relatively early in boot.

 

Can you give this a try and see how it goes?

Edited May 23, 2017 by intvnut

[+nanochess]

IntyBASIC includes code to swap out ECS in case it's connected. Just add this at start of your program to enable it: (turns off secondary PSG)

 

Sound 5,,0
Sound 6,,0
Sound 7,,0
Sound 9,,$38

That's it and also works fine with LTO-Flash. Now you can use the 42K words

[First Spear]

I am using IntyBASIC (duh) and not trying to use any ECS features. I just want to make sure that I can use all of the ROM possible without making my game crash. 42k might be tight for all of the goodies I am trying to pack-in.

 

If IntyBASIC adds additional voices to the music or sound statements, then I would use them, but for now I just want to make sure I don't do something stupid and crash the game if the user has an ECS connected (I know, all 6 people out there haha).

[First Spear]

Will adding that ultimately give me more than 42k for a game, or less? I am not sure about the "style of flipping" but I would want to run on the JLP architecture at the end of the day...

 

Thanks.

 

 

Compatibility with the ECS mainly means page-flipping the ECS ROMs out of the address map so that you can use those address ranges yourself. If you're using a cartridge that supports Mattel-style page flipping, you can simultaneously flip the ECS out while flipping your own game in, even if you don't do any page flipping while the game's running.

 

What I'd recommend is adding a bit of ASM at $4800 to perform the necessary page flips, and tweak your ASM ORG statement for code at $7xxx and $2xxx to put it in, say, page 2. Something like:

.

   ' Disable ECS ROMs
   ASM ORG  $4800
   ASM MVII #$2A52, R0
   ASM MVO  R0, $2FFF
   ASM MVII #$7A52, R0
   ASM MVO  R0, $7FFF
   ASM MVII #$EA52, R0
   ASM MVO  R0, $EFFF
   ASM B    $1041

.

And then elsewhere, instead of saying ASM ORG $7000, say ASM ORG $7000:2. Likewise for ASM ORG $2000 becoming ASM ORG $2000:2.

 

Note that you don't need to do the same for the ROM at $E000, as the ECS early boot sequence never touches that ROM. The code at $4800 should run relatively early in boot.

 

Can you give this a try and see how it goes?

[intvnut]

Short answer: Yes.

 

It disables the ROMs in the ECS and puts your ROMs in its place, freeing up the 12K otherwise occupied by the ECS.

[+nanochess]

I am using IntyBASIC (duh) and not trying to use any ECS features. I just want to make sure that I can use all of the ROM possible without making my game crash. 42k might be tight for all of the goodies I am trying to pack-in.

 

If IntyBASIC adds additional voices to the music or sound statements, then I would use them, but for now I just want to make sure I don't do something stupid and crash the game if the user has an ECS connected (I know, all 6 people out there haha).

It's not that you're using ECS features, it's a short code fragment to help you to turn off ECS if it's connected

 

And allow you to use the whole ROM space.

 

Yet I'm going to check the paging features of LTO-Flash to create a small example of usage.

[First Spear]

So the option is a 30k game if using the ECS, or 42k if no ECS?

[GroovyBee]

So the option is a 30k game if using the ECS, or 42k if no ECS?

 

If you are using the ECS's 8bit RAM, PSG or keyboard/controllers then you can still have a 42K word ROM (or 84K bytes). A 42K word ROM just needs to map out the ECS ROMs so that they don't interfere with the cart's on-board memory map.

[First Spear]

I would like to have 42k available whether an ECS is in or not, and if it is then detect and play 6-voice audio (when that feature becomes available in IntyBASIC). What would be the right set of ASM ORGs and/or "plumbing" code to make that happen? I have used the 42k.bas sample code but I feel like this is the next step and I'm not getting it for some reason.

[GroovyBee]

I would like to have 42k available whether an ECS is in or not, and if it is then detect and play 6-voice audio (when that feature becomes available in IntyBASIC). What would be the right set of ASM ORGs and/or "plumbing" code to make that happen? I have used the 42k.bas sample code but I feel like this is the next step and I'm not getting it for some reason.

 

Some solutions :-

- Use 42k.bas to get the largest ROM space for your game.

- IntyBASIC already supports the PSG in the ECS (see the manual for channel numbers).

- Initialise the ECS PSG into a good state using nanochess's code above.

- If you want to use ECS controllers then use CONT3 and CONT4.

- Use the code here to detect if the ECS is plugged in.

[+DZ-Jay]

I would like to have 42k available whether an ECS is in or not, and if it is then detect and play 6-voice audio (when that feature becomes available in IntyBASIC). What would be the right set of ASM ORGs and/or "plumbing" code to make that happen? I have used the 42k.bas sample code but I feel like this is the next step and I'm not getting it for some reason.

 

I think there's some confusion here. Here's a bit of background that perhaps clears up some of your concerns.

 

The Intellivision Master Controller "boot sequence" includes a check for a signal at a specific address. If it finds it, it will relinquish control to it. This address was intended for "future expansion," which eventually came in the shape of the ECS. So, the result is that if the ECS is plugged in, the Master Controller's EXEC surrenders control to the ECS's EXEC and Bob's your uncle.

 

"But," you ask, "we don't use the EXEC and don't want the ECS's EXEC dirty paws in there either... what to do?" The way that home-brews work around this is the same way we do it when the ECS is not there: we make our program "hijack" control of the main EXEC even before giving it to the ECS's EXEC.

 

So, in order to do this, we need to employ a small piece of code that essentially "bank-switches" the signal address where the main EXEC looks: if it doesn't find what it is looking for in there, it won't call the ECS's EXEC and we continue hijacking on our merry way. That's how we "ignore" the ECS.

 

Notice that all this is only to remove the ECS from the "boot up" equation, that is, we are preventing its EXEC from booting up. The ECS is still very literally plugged in there, so all its features are still around.

 

So, what features does the ECS have?

1. It has a new EXEC (blah! we don't care for it)
2. It has a bit more extended RAM (kinda cool)
3. It has two extra controllers (...cool...)
4. It has another PSG (very cool!)

So it seems that we want everything minus the EXEC. Hold that thought for a second.

 

Now, let's briefly consider life without the ECS and what that "42K" map means:

 

Without the ECS we are free to use any unused part of the Intellivision's address space for our own program. The problem is that all that free and unused address space is not contiguous! Yes, that's the pain: it is split into multiple "segments": some of them for future expansion and others for devices that nobody owns, etc.

 

To make use of this space, we use the "ORG" directive which essentially tells the underlying assembler "start assembling on this other part of memory now..." That way, we fill one of those segments and start filling up another one.

 

Cool? Cool. Now, let's go back to the EXEC.

 

One of those heretofore unused areas has now been ingloriously taken by the ECS's EXEC -- the very EXEC we said we didn't want. Boo! What to do? We use another piece of boiler-plate code that basically "bank-switches" the EXEC code out of sight and treat that space once again as if it were never used.

 

Thus we have achieved two things: First, we've ignored the ECS EXEC during boot-up, keeping control of the program; and second, we've swapped the EXEC memory usage out and returned it to the pool of available ROM addresses.

 

Notice that none of this touches on the PSG or its extra RAM -- the device is still plugged in so we can access those normally (they don't require the EXEC).

 

Thus, the same "42K" map works with or without the EXEC. That "42K" map code in the example that GroovyBee mentioned includes special code to do the two things we wanted: Ignore ECS EXEC during boot up, and make it's ROM free. It does that as part of setting up the "42K" map already.

 

Clear as mud?

 

-dZ.