Color Stack Fiddler

[+DZ-Jay]

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.

 

 

I just traced the execution in the emulator using Mattel's ROMs and the above seems correct. What happens at $7000 and $2000 are merely system initialization. Essentially, the ECS EXEC (when present at $7000), takes over bootstrapping from the main EXEC. The former does invoke routines for block copy and such from the latter during initialization, but controls the bootstrap process.

 

Then eventually, when it gets to $4800 -- which is the PlayCable monitor, and thus in practice never plugged in -- we patch in there and disable the ECS then jump back to the Master Component's EXEC to complete the original system initialization process, wherein eventually it makes its way into Cart.Mac's trap in the "TITLE" routine to update the copyright.

 

At that point Cart.Mac takes over and passes control to the programmer's code.

 

I remember when Joe came up with this work-around, we were making Christmas Carol back then and it took quite a few iterations to of overlaying and patching to get to something actually useful. It was all him, all I did was test in my program and include the first production-ready version of Cart.Mac in Christmas Carol. Eventually, all that bootstrapping code made its way to IntyBASIC and other's projects.

 

It is quite clever, indeed.

 

What I do now in P-Machinery is inject my own initialization routine at $4800 and take over completely from there: At that point, I clear all memory, reset all devices, and jump to game code directly -- bypassing the rest of the EXEC's initialization.

 

-dZ.

[First Spear]

OT.

 

This makes me wonder about the ECS in the Intellivision timeline... Does the ECS have the same bootstrapping code as the Keyboard Component? How could the first Intellivision 2609 console have support for ECS detection/functionality if it came out in '79 and the ECS didn't arrive until years later?

 

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.

[+Lathe26]

OT.

 

This makes me wonder about the ECS in the Intellivision timeline... Does the ECS have the same bootstrapping code as the Keyboard Component? How could the first Intellivision 2609 console have support for ECS detection/functionality if it came out in '79 and the ECS didn't arrive until years later?

 

 

It more that the original Intellivision first looks for code at $7000 and then looks for code at $4800 before finally looking for the standard game header at $5000. Code at $7000 or $4800 has the option to completely take over the system or the code can run for a bit and then let the EXEC resume normal execution. It's more that both the Keyboard Component and the ECS both are designed to have code at $7000 to work with the Intellivision (and not the reverse). Side note, the PlayCable works similarly by having code at $4800.

[First Spear]

(Redacted)

Edited February 15, 2019 by First Spear

[First Spear]

 

 

Papa Intellivision = Genius

 

 

It more that the original Intellivision first looks for code at $7000 and then looks for code at $4800 before finally looking for the standard game header at $5000. Code at $7000 or $4800 has the option to completely take over the system or the code can run for a bit and then let the EXEC resume normal execution. It's more that both the Keyboard Component and the ECS both are designed to have code at $7000 to work with the Intellivision (and not the reverse). Side note, the PlayCable works similarly by having code at $4800.

[+DZ-Jay]

OT.

 

This makes me wonder about the ECS in the Intellivision timeline... Does the ECS have the same bootstrapping code as the Keyboard Component? How could the first Intellivision 2609 console have support for ECS detection/functionality if it came out in '79 and the ECS didn't arrive until years later?

 

 

It's like Lathe26 mentioned: The designers always intended the Intellivision Master Component to be the center of a larger system, so they built in the mechanisms for future expansion. There are two "monitors" built into the EXEC's bootstrap process:

• $4800 - Originally used by the PlayCable
• $7000 - Originally used by the Keyboard Component, then the ECS

These are memory locations into which the EXEC "peeks" to see if there is anything there. If it finds anything, it branches to those locations. It firsts tests the $7000 location, then the $4800. The idea, I suppose, was to bootstrap the Master Component's EXEC, then the Keyboard Component, and possibly then continue to the PlayCable -- while all devices were plugged in.

 

Eventually the Keyboard Component was replaced by the ECS as an actual commercially available peripheral and it took its place by storing its EXEC ROM at the $7000 location. Of course, the PlayCable is no longer available (nor usable). This means that we can tap into the $4800 location for modern expansion modules (or to bootstrap our own home-brewed games).

 

This wasn't unique to the Intellivision, this was actually a common technique for future expansion. I believe old microcomputers like the Commodore-64 did something similar to detect plugged in cartridges at a particular location, then jumping directly to them when they were present.

 

-dZ.