Color Stack Fiddler

[+Lathe26]

Introducing

Color Stack Fiddler

An educational tool for new developers to gain familiarity with the Intellivision's video chip, the STIC, while in Color Stack mode.

Screen menu options:

1. Border Mask setting (toggle all borders off, left-only on, top-only on, left & top on)
2. Screen offset (controlled by disc, display the offset numbers)
3. Select MOBs (disc moves moves the MOB, initially display MOB's position)
4. Toggle Advance color stack at current MOB's position
5. Toggle whether a MOB is Visible, has Priority in front or behind the background, and whether it Interacts with other MOBs/background/border
6. Cycle MOB X/Y Flipping (X on/off, Y on/off)
7. Cycle MOB size (Y = 0.5x, 1x, 2x, 4x and X = 1x, 2x)
8. Toggle MOB Y resolution (1 or 2 cards)
9. Toggle displaying a MOBs position vs or all MOB Collision registers

Pressing side buttons while using the disc will slow down movement, handy for fine-tuned movement.

 

The MOB collision registers are displayed in order from MOB 0 to 7. The bottom-most 12 bits are displayed. It is normal behavior for bits 10 and 11 to always be set. Thus, a MOB that is touching nothing will display a collision value of "C00".

 

Because this is a demo program, all Intellivision colors are displayed which results in the garish appearance.

 

This has been tested on the original Intellivision, a Tutor Pro, and a Keyboard Component.

 

Note that the GRAM cards are are all unique and embed a binary sequence number in the their 3rd line of pixels. It runs from binary 0000b to 1111b.

 

Color Stack Fiddler.zip

Color Stack Fiddler - Source Code.zip

[dontblowincartridge]

Can't get it to run on intySDK the jzintv.exe

 

Seems to crash everytime for me

[+Lathe26]

Can't get it to run on intySDK the jzintv.exe

 

Seems to crash everytime for me

 

What command are you passing into jzintv? Which version of jzintv? Are you using the ROM or building the source code? When you say crash, is jzintv itself crashing or is Color Stack Fiddler crashing inside of jzintv?

 

Also, I'm not familar with IntySDK. Is that IntyBASIC or the old SDK-1600 that's been folded into jzintv or something else entirely?

[dontblowincartridge]

@Lathe26

 

Sorry, what I meant was the intyBASIC SDK v1.1.1 updated to compiler intybasic v1.2.9 and using the current jzintv emulator. I am just using the bash commands provided in the intyBASIC SDK "INTYBUILD" and "INTYRUN". I am building the source code and it does not report any errors or warnings. I looked over the source and didn't notice anything that out of the ordinary compared to other things I have compiled. When I run the built source code the jzintv emulator crashes for me every time. What happens is the screen is black then flashes then the window closes.

 

Not sure why.

Maybe its just me.

[+Lathe26]

What happens if you download the pre-built ROM and load it into jzintv? Does that work or does it crash the same way as from building a ROM from source code?

 

I do have a recollection that jzintv might need the ECS.bin file in addition to EXEC.bin and GROM.bin for some games. If the pre-built ROM doesn't work, see if adding the ECS.bin file helps.

[+DZ-Jay]

@Lathe26

 

Sorry, what I meant was the intyBASIC SDK v1.1.1 updated to compiler intybasic v1.2.9 and using the current jzintv emulator. I am just using the bash commands provided in the intyBASIC SDK "INTYBUILD" and "INTYRUN". I am building the source code and it does not report any errors or warnings. I looked over the source and didn't notice anything that out of the ordinary compared to other things I have compiled. When I run the built source code the jzintv emulator crashes for me every time. What happens is the screen is black then flashes then the window closes.

 

Not sure why.

Maybe its just me.

 

I tried building it with the latest IntyBASIC SDK using the IntyBASIC compiler v1.2.9 and it failed with a myriad errors. How did you get it to build with the SDK?

 

I also cannot get it to run with the IntyBASIC SDK. It is something to do with the "miniexec.bin" and "minigrom.bin" files used by the SDK. When I replace them with the originals, it works.

 

-dZ.

[+DZ-Jay]

What happens if you download the pre-built ROM and load it into jzintv? Does that work or does it crash the same way as from building a ROM from source code?

 

I do have a recollection that jzintv might need the ECS.bin file in addition to EXEC.bin and GROM.bin for some games. If the pre-built ROM doesn't work, see if adding the ECS.bin file helps.

 

It does not need the ECS.bin for your program to work, but apparently it fails with the non-infringing minimal versions of the EXEC and GROM. Are you making EXEC calls from your program?

 

-dZ.

[+Lathe26]

 

I tried building it with the latest IntyBASIC SDK using the IntyBASIC compiler v1.2.9 and it failed with a myriad errors. How did you get it to build with the SDK?

 

I also cannot get it to run with the IntyBASIC SDK. It is something to do with the "miniexec.bin" and "minigrom.bin" files used by the SDK. When I replace them with the originals, it works.

 

-dZ.

To build it, I open a command prompt on Windows 10, go to the folder where the source code is stored, and type "build.cmd". Make sure that you update your local copy of build.cmd to point the paths to where IntyBASIC and jzintv are located. I build this successfully with:

• intybasic_compiler_v1.2.9
• jzintv-20180509-win32

What errors are you seeing? Also, when you say "run with INTYBASIC SDK", did you mean jzintv or something else?

 

 

It does not need the ECS.bin for your program to work, but apparently it fails with the non-infringing minimal versions of the EXEC and GROM. Are you making EXEC calls from your program?

 

-dZ.

No calls to the EXEC that I have written. The prologue/epilogue were modified by Joe Z to support the Tutorvision/Tutor Pro systems. I doubt that there are EXEC calls in his code, but I haven't asked him either.

 

I never use the minimal versions of the EXEC and GROM since those fail for some of the original games too.

[+Lathe26]

I'll have to try out the INTYBUILD and INTYRUN commands. I never used those since the early work-arounds for the --cc3 bug used extra command-line steps (still true for IntyBASIC's Keyboard Component compatibility issues but those don't apply to Color Stack Fiddler).

[+DZ-Jay]

 

To build it, I open a command prompt on Windows 10, go to the folder where the source code is stored, and type "build.cmd". Make sure that you update your local copy of build.cmd to point the paths to where IntyBASIC and jzintv are located. I build this successfully with:

• intybasic_compiler_v1.2.9
• jzintv-20180509-win32

What errors are you seeing? Also, when you say "run with INTYBASIC SDK", did you mean jzintv or something else?

 

 

No calls to the EXEC that I have written. The prologue/epilogue were modified by Joe Z to support the Tutorvision/Tutor Pro systems. I doubt that there are EXEC calls in his code, but I haven't asked him either.

 

I never use the minimal versions of the EXEC and GROM since those fail for some of the original games too.

 

 

The problem is the change to the prologue/epilogue. The IntyBASIC SDK is intended to build SDK projects in an easy and intuitive way. Therefore, it doesn't use any custom prologue or epilogue, it automatically invokes the compiler with those in its include "lib" folder. The same with the "constants.bas" file. It sets the environment automatically, and invokes the tools with the proper contexts and paths.

 

If you want to use the IntyBASIC SDK to build projects not originally created with it, you will have to modify the project to fit the SDK's expectations: that is, you will have to replace the "constants.bas" and the epilogue and prologue in the "lib" folder.

 

However, I wouldn't recommend doing that, for it may brake all other SDK projects.

 

-dZ.

[+DZ-Jay]

I'll have to try out the INTYBUILD and INTYRUN commands. I never used those since the early work-arounds for the --cc3 bug used extra command-line steps (still true for IntyBASIC's Keyboard Component compatibility issues but those don't apply to Color Stack Fiddler).

 

What "early work-arounds for the --cc3 bug"?

 

By the way, I have a new version of the IntyBASIC SDK that I will release soon.

 

-dZ.

[+Lathe26]

 

What "early work-arounds for the --cc3 bug"?

 

By the way, I have a new version of the IntyBASIC SDK that I will release soon.

 

-dZ.

 

The bug with --cc3 is that this command-line option for IntyBASIC.exe does not function properly. There are a couple AA threads (ex: http://atariage.com/forums/topic/280038-score-is-always-shown-as-65535/?p=4055606) that go into details but the short version is that IntyBASIC.exe does not output the ASM file with the appropriate MEMATTR for the extra RAM it tries to use.

 

The first recommended work-around I found online was to have as1600.exe output BIN+CFG, add the [memattr] section to the CFG, then run bin2rom.

 

Later, a better work-around was found by simply adding the following line to the BAS file:

ASM MEMATTR $8000, $9FFF, "+RW"

[+Lathe26]

 

It does not need the ECS.bin for your program to work, but apparently it fails with the non-infringing minimal versions of the EXEC and GROM. Are you making EXEC calls from your program?

 

-dZ.

 

 

 

The problem is the change to the prologue/epilogue. The IntyBASIC SDK is intended to build SDK projects in an easy and intuitive way. Therefore, it doesn't use any custom prologue or epilogue, it automatically invokes the compiler with those in its include "lib" folder. The same with the "constants.bas" file. It sets the environment automatically, and invokes the tools with the proper contexts and paths.

 

If you want to use the IntyBASIC SDK to build projects not originally created with it, you will have to modify the project to fit the SDK's expectations: that is, you will have to replace the "constants.bas" and the epilogue and prologue in the "lib" folder.

 

However, I wouldn't recommend doing that, for it may brake all other SDK projects.

 

-dZ.

 

I just completed a series of tests with the latest IntyBASIC and latest jzintv. I have not yet downloaded or tried IntyBASIC SDK but am currently concerned it is complicating matters. Hopefully, we can get things untangled.

 

Issue #1

Looks like jzintv has a bug with handling "CFGVAR "ecs_compat" = 2" where jzintv locks up on launch. The value of 2 is supposed to mean that the ROM is enhanced by the presence of an ECS but the ECS is not required (value of 3 would mean ECS required). Unfortunately, if ecs.bin is missing, jzintv prints out the following error message:

errno value e: No such file or directory

ERROR: Could not read ECS ROM image 'ecs.bin'

If ecs.bin is present or if the cfgvar line is commented out, then jzintv does not lock up. I'll contact Joe Z about this.

 

Recommended work-around: make sure that ecs.bin is loadable by jzintv.

 

Issue #2

Color Stack Fiddler crashes in jzintv if miniexec is used instead of the real Mattel exec.bin. Switching between the fixed prologue/epilogue and the original (buggy) prologue/epilogue has no effect. Therefore the crash with miniexec is somewhere else. The BAS file is just ordinary IntyBASIC code so I have no idea why the crash is occurring with miniexec (did I hook the EXEC or is it being done under the hood or something different?). I'll contact Oscar about this. Ok, I just figured out what is hooking the EXEC... it's the ECS code that is loaded at $7000, starts executing, and tries to jump back to the EXEC's $1738 address (in the real EXEC this address is a PSHR R5 but in the miniexec this is a HLT).

 

Recommended work-around: use the real Mattel exec.bin

 

Issue #3

IntyBASIC code is normally incompatible with some hardware (a small minority) because of its prologue/epilogue (i.e. the "original prologue/epilogue"). Because there appears to be no negative effects with using the fixed prologue/epilogue, it might be a good idea to include the fixed files with IntyBASIC SDK as a hardware work-around. In the meantime, I'll contact Oscar about getting the fixed files into IntyBASIC itself.

 

Recommended work-around: developers should switch to using the fixed versions of prologue/epilogue

 

Issue #4

IntyBASIC.exe's --cc3 option does not quite generate correct code (see previous post). I'll contact Oscar about this.

 

Recommended work-around: add the following code to BAS files: ASM MEMATTR $8000, $9FFF, "+RW"

 

Issue #5

IntyBASIC.exe's --cc3 option generates code that isn't compatible with the Keyboard Component, even when the above work-around is used. This is because of a memory conflict with the KC's 10-bit RAM. This issue is a bit off-topic from Color Stack Fiddler. This might not be a bug but rather a new feature of IntyBASIC.exe. I'll contact Oscar about this.

[+Lathe26]

@Lathe26

 

Sorry, what I meant was the intyBASIC SDK v1.1.1 updated to compiler intybasic v1.2.9 and using the current jzintv emulator. I am just using the bash commands provided in the intyBASIC SDK "INTYBUILD" and "INTYRUN". I am building the source code and it does not report any errors or warnings. I looked over the source and didn't notice anything that out of the ordinary compared to other things I have compiled. When I run the built source code the jzintv emulator crashes for me every time. What happens is the screen is black then flashes then the window closes.

 

Not sure why.

Maybe its just me.

 

I know there is a bunch stuff mentioned in the above posts. Please try one of these:

 

Option 1: Add ecs.bin and update exec.bin to the real Mattel exec.bin. You'll need to find these two files on the Internet somewhere. jzintv ships with an unofficial re-written exec.bin (for copyright reasons) that is compatible with only some Intellvision games. This should allow you to either:

1. Just run the pre-built ROM in the original post
2. Rebuild Color Stack Fiddler from source code

Option 2: Comment out or delete the entire line in ColorStackFiddler.bas that says "ASM CFGVAR "ecs_compat" = 2". This won't fix the pre-built ROM in the original post, but it should allow you:

1. Rebuild Color Stack Fiddler from source code

Note: I have not tried using IntyBASIC SDK yet. However, the 2 above options will hopefully help.

[+Lathe26]

Just want to add that I appreciate the feedback on Color Stack Fiddler. Finding bugs is good; it makes code better. My code is not perfect and my assessments above could have mistakes.

[+DZ-Jay]

The bug with --cc3 is that this command-line option for IntyBASIC.exe does not function properly. There are a couple AA threads (ex: http://atariage.com/forums/topic/280038-score-is-always-shown-as-65535/?p=4055606) that go into details but the short version is that IntyBASIC.exe does not output the ASM file with the appropriate MEMATTR for the extra RAM it tries to use.

 

The first recommended work-around I found online was to have as1600.exe output BIN+CFG, add the [memattr] section to the CFG, then run bin2rom.

 

Later, a better work-around was found by simply adding the following line to the BAS file:

ASM MEMATTR $8000, $9FFF, "+RW"

 

Ah. Well, as far as the SDK is concerned, all you have to do is replace IntyBASIC.exe with a fixed one.

 

 

I just completed a series of tests with the latest IntyBASIC and latest jzintv. I have not yet downloaded or tried IntyBASIC SDK but am currently concerned it is complicating matters. Hopefully, we can get things untangled.

 

I don't see how the SDK "complicates matters" when all it does is invoke intybasic.exe and as1600 with standard command line parameters, and using a pre-set environment path instead of forcing people to type it in themselves on the command line, or create their own arcane batch files for every project.

 

If you mean it makes it hard to build a project which was not intended to be used with the SDK, then yes, that is true. However, if you didn't create your project with the IntyBASIC SDK in mind then I wouldn't expect it to.

 

 

 

Issue #1

Looks like jzintv has a bug with handling "CFGVAR "ecs_compat" = 2" where jzintv locks up on launch. The value of 2 is supposed to mean that the ROM is enhanced by the presence of an ECS but the ECS is not required (value of 3 would mean ECS required). Unfortunately, if ecs.bin is missing, jzintv prints out the following error message:

errno value e: No such file or directory

ERROR: Could not read ECS ROM image 'ecs.bin'

If ecs.bin is present or if the cfgvar line is commented out, then jzintv does not lock up. I'll contact Joe Z about this.

 

Recommended work-around: make sure that ecs.bin is loadable by jzintv.

 

 

I was able to execute your provided ROM without the ecs.bin loaded, merely by switching the "miniexec" and "minigrom" files with Mattel's, so that doesn't seem to be a requirement. At least not for the ROM. Perhaps building from source adds the requirement.

 

Issue #2

Color Stack Fiddler crashes in jzintv if miniexec is used instead of the real Mattel exec.bin. Switching between the fixed prologue/epilogue and the original (buggy) prologue/epilogue has no effect. Therefore the crash with miniexec is somewhere else. The BAS file is just ordinary IntyBASIC code so I have no idea why the crash is occurring with miniexec (did I hook the EXEC or is it being done under the hood or something different?). I'll contact Oscar about this. Ok, I just figured out what is hooking the EXEC... it's the ECS code that is loaded at $7000, starts executing, and tries to jump back to the EXEC's $1738 address (in the real EXEC this address is a PSHR R5 but in the miniexec this is a HLT).

 

Recommended work-around: use the real Mattel exec.bin

 

 

There are intellectual property concerns about that, and it is not something I would direct people to do willy nilly. An alternative would be to patch the miniexec.bin if it is faulty.

 

Issue #3

IntyBASIC code is normally incompatible with some hardware (a small minority) because of its prologue/epilogue (i.e. the "original prologue/epilogue"). Because there appears to be no negative effects with using the fixed prologue/epilogue, it might be a good idea to include the fixed files with IntyBASIC SDK as a hardware work-around. In the meantime, I'll contact Oscar about getting the fixed files into IntyBASIC itself.

 

Recommended work-around: developers should switch to using the fixed versions of prologue/epilogue

 

 

Before asking people to switch sensitive files which are the lifeblood of IntyBASIC, I would recommend we get a fixed version directly from Oscar. He has said he was working on one more release, and it would have a very negative impact on compatibility if people cannot upgrade due to a divergent version of the libraries.

 

To me at least, "there appears to be no negative effects" is a low bar of quality assurance for anybody currently using the tools successfully. I'm not saying there is anything wrong with the files, I haven't tested them, just that people shouldn't further affect their environment if it isn't currently broken.

 

In my opinion, those issues are exceedingly rare edge cases which may not affect most people already using IntyBASIC or the IntyBASIC SDK successfully, so I wouldn't recommend rushing to any action until the distributed tools are fixed -- unless someone has a dire need to address them.

 

-dZ.

[+DZ-Jay]

I know there is a bunch stuff mentioned in the above posts. Please try one of these:

 

Option 1: Add ecs.bin and update exec.bin to the real Mattel exec.bin. You'll need to find these two files on the Internet somewhere. jzintv ships with an unofficial re-written exec.bin (for copyright reasons) that is compatible with only some Intellvision games. This should allow you to either:

 

It should be compatible with any new project. It will not be compatible with any ROM from Mattel or anything that uses the EXEC. For projects built using the IntyBASIC SDK, it should work fine, since there shouldn't be any reliance on the EXEC except the bootstrap sequence.

 

If there is a bug in the way that the "miniexec" treats the ECS monitor, perhaps we should address that.

 

Another alternative is to talk to Tallarico and Co. (or whoever owns the property now) and see if they are willing to extend a license for use of the ROMs for non-commercial use in emulation and development.

 

• 2: Comment out or delete the entire line in ColorStackFiddler.bas that says "ASM CFGVAR "ecs_compat" = 2". This won't fix the pre-built ROM in the original post, but it should allow you:

• Rebuild Color Stack Fiddler from source code

Note: I have not tried using IntyBASIC SDK yet. However, the 2 above options will hopefully help.

 

#2 won't work with the IntyBASIC SDK unless the "epilogue" and "prologue" files are replaced in the "lib" folder, or the tool scripts are modified to allow pointing them somewhere else.

 

Part of the problem that the IntyBASIC SDK is trying to solve is providing users working tools without the complication of having to set up paths, the environment, or copy+pasting files around just to have everything dumped in a single folder, every time. It partitions the project structure by defining a clear "library" of public modules (like the epilogue, prologue, constants, etc.), a "binary" folder for the SDK tools and compilers, and a "rom" folder for the necessary emulation ROMs." Then there's a special "Projects" folder which is the user workspace, with individual project folders, and each one is split into source, asm, and bin folders, to help users find stuff in the right way.

 

Because the SDK environment follows a standard structure convention, it knows where everything is, and it allows users to use the same tools identically on every project by just using the project name, rather than having to figure out where everything is, or create arcane command lines.

 

We can always enhance the tools, it was intended to be a community effort.

 

However, that simplicity must be maintained for the SDK to be useful. Otherwise, why use it at all?

 

-dZ.

[+DZ-Jay]

By the way, in the "CART.MAC" macro library, Joe Z. included an overlay using bank-switching to prevent the ECS monitor at $4800 from kicking in. The reason is that, even with the ECS plugged in, home-brews wouldn't be using the ECS EXEC, just like they wouldn't use the regular EXEC, and just bypass it. It also allows that memory space to be added to the available cartridge ROM memory map.

 

Perhaps that should be included in the IntyBASIC prologue, or at least as an option. Alternatively, I could add it to a default library in the IntyBASIC SDK, to be included automatically on every new project.

 

-dZ.

[+nanochess]

IntyBASIC includes a mechanism to disable the ECS ROM by default.

 

It's enough to use SOUND 9,,$38 as the first statement of program, and IntyBASIC will generate code to disable ECS.

 

I need of course make it more elegant, but it's a small and quick solution.

[+DZ-Jay]

IntyBASIC includes a mechanism to disable the ECS ROM by default.

 

It's enough to use SOUND 9,,$38 as the first statement of program, and IntyBASIC will generate code to disable ECS.

 

I need of course make it more elegant, but it's a small and quick solution.

 

Cool, thanks for that. Perhaps I should include that in the default template for new projects automatically, with an option to skip it.

 

-dZ.

[+Lathe26]

I was able to execute your provided ROM without the ecs.bin loaded, merely by switching the "miniexec" and "minigrom" files with Mattel's, so that doesn't seem to be a requirement. At least not for the ROM. Perhaps building from source adds the requirement.

 

I suspect you ran your tests with the provided ROM with the out-of-date jzintv.exe that ships as part of IntyBASIC SDK. That was the only way I was able to repeat your results. When jzintv.exe is updated inside of IntyBASIC SDK to the latest version, the lockup bug in jzintv is confirmed to occur. Also, in discussions with Joe Z over email, he's found where the bug is in the latest released jzintv source code.

 

 

In my opinion, those issues are exceedingly rare edge cases which may not affect most people already using IntyBASIC or the IntyBASIC SDK successfully, so I wouldn't recommend rushing to any action until the distributed tools are fixed -- unless someone has a dire need to address them.

 

Tutor Pro and Tutorvision hardware is rare. In my case, I had dire need to code my Tutor Pro to test out its unique STIC chip.

 

 

If there is a bug in the way that the "miniexec" treats the ECS monitor, perhaps we should address that.

 

Another alternative is to talk to Tallarico and Co. (or whoever owns the property now) and see if they are willing to extend a license for use of the ROMs for non-commercial use in emulation and development.

 

Getting the real EXEC and ECS ROMs released by either Intellivision Entertainment or the new Blue Sky Rangers company would be the best option.

 

If that doesn't work, then updating miniexec to become ecs.bin compatible would be technically interesting but would only fix 1/2 of the copyright issues. Miniexec was created to avoid copyright issues. Users would still be downloading ecs.bin which is also a copyright issue.

 

Perhaps someone should create a miniecs.bin file. The simplest implementation (and admittedly lame) would be to have $7000 execute code to bankswap the appropriate 4K blocks of its ROM and then either just "RETURN" or "J <good_miniexec_address>". The rest of miniecs would just be filled with $0000 (the HLT instruction) which is the same thing that most of miniexec is already filled with.

 

 

#2 won't work with the IntyBASIC SDK unless the "epilogue" and "prologue" files are replaced in the "lib" folder, or the tool scripts are modified to allow pointing them somewhere else.

 

Actually, the epilogue and prologue files have nothing to do with the crash that dontblowincartridge is seeing. #2 should work but I'd like confirmation from him with his modified IntyBASIC SDK environment. Color Stack Fiddler will compile and run fine with the old prologue/epilogue files or with the fixed files. The only change is whether the compiled code will run on Tutor Pros or Tutorvisions.

 

The crash is confirmed as an incompatibility between the force-loaded ecs.bin file and the miniexec.

[+DZ-Jay]

I suspect you ran your tests with the provided ROM with the out-of-date jzintv.exe that ships as part of IntyBASIC SDK. That was the only way I was able to repeat your results. When jzintv.exe is updated inside of IntyBASIC SDK to the latest version, the lockup bug in jzintv is confirmed to occur. Also, in discussions with Joe Z over email, he's found where the bug is in the latest released jzintv source code.

 

 

Strange, I used the latest version of the SDK, which I have here ready. It includes the latest jzintv, as1600, and Intybasic binaries, as of about a month ago. I'll check again just in case.

 

Tutor Pro and Tutorvision hardware is rare. In my case, I had dire need to code my Tutor Pro to test out its unique STIC chip.

 

I understand, and that's fair. I just thought it was a bit wild to extrapolate from your edge case and recommend to others to "patch" their environments to address the problem that may not affect them.

 

Getting the real EXEC and ECS ROMs released by either Intellivision Entertainment or the new Blue Sky Rangers company would be the best option.

 

I agree. I'll try to reach out to them about it, but I don't have any influence with them, and I suspect they don't even know who I am, so I don't know how far that'll get. I hope other, more prominent members of the community step up and try as well.

 

It would be ideal if the home-brew community were allowed to run and test their games using the real ROM images. The IntyBASIC SDK and SDK-1600, after all, are non-commercial tool kits.

 

 

If that doesn't work, then updating miniexec to become ecs.bin compatible would be technically interesting but would only fix 1/2 of the copyright issues. Miniexec was created to avoid copyright issues. Users would still be downloading ecs.bin which is also a copyright issue.

 

 

I do not think you need original ecs.bin at all, not for home-brews. If you want to run Mattel ROMs in emulation, yes, but for developing home-brews, we should all be bypassing the ECS EXEC completely.

 

We depend on the Master Component's EXEC because it includes the machine's bootstrap sequence and the VBLANK trap, but the ECS EXEC offers nothing to home-brewers (nothing that we should be using if we want to stay clear of intellectual property issues).

 

Perhaps I'm missing something, but I imagine that fixing the "miniexec" bootstrap and adding code to the compiler (or program ROM header template) to switch out the ECS EXEC at the $4800 monitor should suffice. No?

 

Perhaps someone should create a miniecs.bin file. The simplest implementation (and admittedly lame) would be to have $7000 execute code to bankswap the appropriate 4K blocks of its ROM and then either just "RETURN" or "J <good_miniexec_address>". The rest of miniecs would just be filled with $0000 (the HLT instruction) which is the same thing that most of miniexec is already filled with.

 

But we do not need that. As far as I understand, we just need to trap at $4800 and avoid initiating the ECS EXEC at all. That's done successfully with lots of games already out there.

 

Actually, the epilogue and prologue files have nothing to do with the crash that dontblowincartridge is seeing. #2 should work but I'd like confirmation from him with his modified IntyBASIC SDK environment. Color Stack Fiddler will compile and run fine with the old prologue/epilogue files or with the fixed files. The only change is whether the compiled code will run on Tutor Pros or Tutorvisions.

 

The libraries do not contribute to the crash, but they are the reason that the IntyBASIC SDK fails to build the source. When I switched the "intybuild" script in my local SDK installation to use the epilogue/prologue/constants you provided, it built fine.

 

 

The crash is confirmed as an incompatibility between the force-loaded ecs.bin file and the miniexec.

 

There are two issues at play here:

1. The crash of the provided ROM originally reported, and
2. The build error when attempting to compile with the IntyBASIC SDK.

My responses have been aimed at the second issue, which you mentioned you hadn't tested, but suggested that it could be some "problem" with the SDK. I was trying to explain why the SDK was not compatible with your source nor your binary:

1. The binary crashes due to the miniexec issue, and
2. The compiler fails because it uses the stock library files included with IntyBASIC, not your modified versions.

That is all.

 

-dZ.

[+Lathe26]

I understand, and that's fair. I just thought it was a bit wild to extrapolate from your edge case and recommend to others to "patch" their environments to address the problem that may not affect them.

The patching recommendation was mainly just to help developers avoid the hassle and possibly noisy complaints of few returned games if they chose to sell their programs. There would be few, if any, such returned games since there aren't too many Tutor Pros out there. Tutor Pro compatibility isn't a big deal for free software. However, a user who paid $60+ for a CIB cartridge that doesn't work on their system might get miffed, especially if they have no idea that their one and only console is a Tutor Pro. I don't think anyone has knowingly sold a Tutor Pro yet which is why there is suspicion that there are a few more hiding in plain sight

 

That all said, it's most likely fine to just wait for an upstream update to IntyBASIC.

 

 

I do not think you need original ecs.bin at all, not for home-brews. If you want to run Mattel ROMs in emulation, yes, but for developing home-brews, we should all be bypassing the ECS EXEC completely.

 

We depend on the Master Component's EXEC because it includes the machine's bootstrap sequence and the VBLANK trap, but the ECS EXEC offers nothing to home-brewers (nothing that we should be using if we want to stay clear of intellectual property issues).

 

Adding the miniecs.bin was mainly to just work-around the 2 confirmed bugs where jzintv forces the use of ecs.bin (to avoid the lockup) and that ecs.bin hooks into the EXEC in ways that causes miniexec.bin to execute an HLT before any game code is executed. Creating miniecs also works around the copyright concerns of downloading ecs.bin. Once a new version of jzintv is released, both ecs.bin or miniecs are unnecessary.

 

 

Perhaps I'm missing something, but I imagine that fixing the "miniexec" bootstrap and adding code to the compiler (or program ROM header template) to switch out the ECS EXEC at the $4800 monitor should suffice. No?

 

But we do not need that. As far as I understand, we just need to trap at $4800 and avoid initiating the ECS EXEC at all. That's done successfully with lots of games already out there.

 

Has it been confirmed that $4800 is be an alternative work-around to avoid executing ECS ROMs? According to one source of documentation, it won't work because $7000 is probed for and executed before $4800 is probed for and executed. I'll have to check out the CART.MAC file to see what it does since it sounds like it contradicts that documentation.

 

 

The libraries do not contribute to the crash, but they are the reason that the IntyBASIC SDK fails to build the source. When I switched the "intybuild" script in my local SDK installation to use the epilogue/prologue/constants you provided, it built fine.

 

There are two issues at play here:

• The crash of the provided ROM originally reported, and
• The build error when attempting to compile with the IntyBASIC SDK.

My responses have been aimed at the second issue, which you mentioned you hadn't tested, but suggested that it could be some "problem" with the SDK. I was trying to explain why the SDK was not compatible with your source nor your binary:

• The binary crashes due to the miniexec issue, and
• The compiler fails because it uses the stock library files included with IntyBASIC, not your modified versions.

That is all.

 

I was unaware that the prologue/epilogue files were the cause of your compiling issues. dontblowincartridge appears to have successfully built the code so I was focused on his issue.

 

Which version of jzintv and IntyBASIC are you building with? The IntyBASIC SDK 1.1.1 uses out-of-date versions of IntyBASIC and jzintv. I noticed that the 1.1.1 release also uses a 3rd version of the prologue/epilogue files. The prologue/epilogue files I've tested with are from IntyBASIC 1.2.9 (what I called "original") and from Joe Z (what I called "fixed"). The prologue/epilogue files in IntyBASIC SDK 1.1.1 are older then either of those files, which I am guessing is from IntyBASIC 1.2.8. Color Stack Fiddler is confirmed to compile with both the 1.2.9 stock files and the fixed files, at least outside of IntyBASIC SDK.

[+DZ-Jay]

 

Which version of jzintv and IntyBASIC are you building with? The IntyBASIC SDK 1.1.1 uses out-of-date versions of IntyBASIC and jzintv. I noticed that the 1.1.1 release also uses a 3rd version of the prologue/epilogue files. The prologue/epilogue files I've tested with are from IntyBASIC 1.2.9 (what I called "original") and from Joe Z (what I called "fixed"). The prologue/epilogue files in IntyBASIC SDK 1.1.1 are older then either of those files, which I am guessing is from IntyBASIC 1.2.8. Color Stack Fiddler is confirmed to compile with both the 1.2.9 stock files and the fixed files, at least outside of IntyBASIC SDK.

 

I'm using the last IntyBASIC and jzIntv. I have a new version of the IntyBASIC SDK which I have yet to release and it has the latest of everything.

 

I just tried again and it worked fine. It was the stupid Mac version of the intybasic compiler, which chokes on Windows line-endings apparently. I just reformatted the source to replace \r\n with \n and it compiled. The prologue and epilogue thing was a red herring, sorry.

 

Oscar should really look into making the intybasic compiler coalesce whitespace smartly rather than expect specific characters as token delimiters.

 

-dZ.

[+Lathe26]

A little off-topic: I just looked at cart.mac and it's impressive in how it works, especially since the ECS code executes before any code at $4800 can execute.

 

Yes, the EXEC runs code at $7000 first before $4800 gets to execute. At first glance, this fact makes it appear impossible for $4800 to useful.

 

However, the way cart.mac works around this is by taking advantage of that the CC3 and LTO can map memory in 256 byte increments (i.e. not limited to large 2K or 4K blocks). By only allowing game ROMs to map memory at $2100-$2FFF and $7100-7FFF (I'm ignoring the "bank F" alternative implementation), it leaves a small amount of ECS ROM code available at $2000-$20FF and $7000-70FF. Based off of this, I suspect that the following is occurring:

1. Intellivision starts with executing from the EXEC after reset
2. EXEC probes and finds that the ECS's $7000 is present.
3. Execution jumps to ECS ROM at $7000 and executes a small amount of code there.
4. Soon afterwards, execution moves to the $2000-$20FF range in the ECS ROM
5. Execution returns to the EXEC
6. EXEC probes and finds that the game's $4800 is present.
7. Execution jumps to the game's $4800
8. This code disables the ECS ROM's which eliminates any conflict between the game's ROM and ECS's ROM where there address ranges overlapped.
9. Execution returns to the EXEC
10. Execution jumps to the $5000 range and continues normally

I might not have things exact, but this is likely close enough. cart.mac is quite clever.