Programming Questions

[pimpmaul69]

There are a few Apple ]['ers here and there, sharing the love.

 

since i play tons of emulated systems on my ultimate intellivision flashback raspberry pi that i have modified controllers for every system. I even modified one for the apple ii. I have devalued several pricey controllers for this cause.

[Walter Ives]

On 10/10/2015 at 9:26 AM, DZ-Jay said:

The CPU is then hard-wired to call a specific chunk of code in the EXEC ROM to handle the interrupt signal. This cannot be altered or avoided without actual physical hardware modifications*.

Not exactly. The interrupt vector is stored in the RO-3-9502 EXEC ROM, which provides it when it gets an IAB. A device plugged into the cartridge slot can provide a different interrupt vector. If it's civilized, that device will zero BC2 before it loops it back to disable IAB to the EXEC ROM.

 

WJI

[Walter Ives]

On 10/10/2015 at 9:26 AM, DZ-Jay said:

And for those of you with hardcore technical chops, just in case you were wondering: the VBLANK interrupt is the ONLY one that is enabled in the Intellivision CPU, and the only one to which a program has access (via the ISR interrupt vector). This means that there is no way to "chase the beam" like they do in other platforms to multiplex objects during "horizontal retrace."

SR1 (VBLANK) is connected to the CPU's maskable interrupt input, which was intended to be able to accept interrupts from multiple devices. A cartridge could assert additional interrupts by jamming SR1, but that would likely affect the GROM's access mode and thereby interfere with the STIC's access to graphics memory. On the other hand, it would be relatively easy to put a readable line counter on a cartridge that was cleared on SR1 and incremented every CBLNK.

 

WJI

[Walter Ives]

On 10/10/2015 at 9:26 AM, DZ-Jay said:

Although you cannot remove or alter the hardware interrupt, you can actually tell the CPU to ignore it momentarily. This is typically done in long-running initialization routines that may take longer than a frame to set up.

The DIS instruction disables interrupts for as long as you want, that is to say potentially much longer than momentarily. Indeed, interrupts are disabled on reset and have to be explicitly enabled, usually with an EIS instruction. Of course, without interrupts you'll have a harder time tickling the CPU/STIC bit to enable the display.

WJI

[Walter Ives]

On 10/11/2015 at 8:16 AM, freewheel said:

Assume that I have not much more than a conceptual understanding, and that I only read the book about it: were there other systems than the VCS where you could "chase the beam"? With the VCS you HAD to... I thought this was abstracted away from programmers on pretty much every other platform.

Intellivision programs have to chase the beam when shuffling BACKTAB while scrolling. Also when doing effects like Star Strike.

 

WJI

[+DZ-Jay]

20 hours ago, Walter Ives said:

Not exactly. The interrupt vector is stored in the RO-3-9502 EXEC ROM, which provides it when it gets an IAB. A device plugged into the cartridge slot can provide a different interrupt vector. If it's civilized, that device will zero BC2 before it loops it back to disable IAB to the EXEC ROM.

 

WJI

 

Pardon me if the following sounds stupid or if I use the wrong terms -- I am not an engineer and certainly ignorant of most electronics concepts.

 

Is the vector to which you refer, the one that invokes the EXEC handler when the signal arrives, or the one the EXEC invokes subsequently after saving the system state?

 

As far as I know, the CPU will always invoke the short EXEC routine that stores the system state and passes control to the interrupt service routine in the ISR vector.  That was what my original post was intended to convey:  that the interrupt itself is a hardware feature, even if its handling is done in software.

 

Are you suggesting that the cartridge could intercept the signal before it goes to the EXEC first?

 

 

 

20 hours ago, Walter Ives said:

The DIS instruction disables interrupts for as long as you want, that is to say potentially much longer than momentarily. Indeed, interrupts are disabled on reset and have to be explicitly enabled, usually with an EIS instruction. Of course, without interrupts you'll have a harder time tickling the CPU/STIC bit to enable the display.

 

WJI

 

Well, I meant "momentarily" in practical terms.  As you suggest, an Intellivision program that disables interrupts and never re-enables them is not very useful.

Although, I suppose you could write your code in a way that accounts for all clock cycles incurred at any point, and handle the display by somehow magically aligning your update routine flow to the timing of bus and STIC states ...

 

But then, if you are so hungry for a punishing challenge, there are more punishing problems out there to suffer on.

 

20 hours ago, Walter Ives said:

Intellivision programs have to chase the beam when shuffling BACKTAB while scrolling. Also when doing effects like Star Strike.

 

WJI

Fair enough.  Although I wouldn't call that "chasing the beam," as most understand it from the term's application in other platforms.  Chasing the STIC buffer pre-fetch, maybe?

 

Yes, scrolling (and any significantly large BACKTAB updates, for that matter) need to stay ahead of the STIC fetching the data from System RAM, but the timing is less critical than that of the actual raster on, say, a VCS.

 

There are, after all, several thousand cycles before the fetching starts, and copying an entire row can be done quite fast, that as long as you start early enough in the frame, you can stay ahead and even gain ground on every row block-copy.

 

Cycling GRAM like Star Strike does is also less punishing.  I mean, it is fairly trivial to copy, say, 16 cards (that covers all 8 MOBs set to use GRAM at double vertical resolution, animating at once) and still have time to scroll and shift the BACKTAB.
 

All that notwithstanding, I agree with your general point that Intellivision programmers are not absolved from time-critical graphics handling -- we just have a much easier time at it than other platforms. 

 

    dZ.

[Walter Ives]

On 2/13/2023 at 5:36 AM, DZ-Jay said:

Is the vector to which you refer, the one that invokes the EXEC handler when the signal arrives, or the one the EXEC invokes subsequently after saving the system state?

 

As far as I know, the CPU will always invoke the short EXEC routine that stores the system state and passes control to the interrupt service routine in the ISR vector.  That was what my original post was intended to convey:  that the interrupt itself is a hardware feature, even if its handling is done in software.

 

Are you suggesting that the cartridge could intercept the signal before it goes to the EXEC first?

    The former. The interrupt vector is not provided by the CPU. The CP-1600 interrupt system is modeled after the PDP-11's, and there it was the interrupting device that was nominally responsible for providing the interrupt vector.

    When the CP-1600 responds to an interrupt it issues an IAB ("Interrupt address to bus") cycle to request the interrupt vector from the interrupting device. It is incumbent upon the system designer to provide a mechanism for providing this vector. On the Master Component that is done by the EXEC ROM rather than the STIC chip. You understood that right: the interrupt (and reset) vectors, $1004 and $1000, are stored in the EXEC ROM, specifically in two dedicated 16-bit words that are not part of the 2K x 10 memory array and so not in the CPU's address space. The only way to access them is with an IAB.

    However, the CPU's three bus control signals don't go directly to the on-bard ROMs, they are looped through the cartridge port first. All you have to do to replace the vectors with ones of your own is put a circuit on the cartridge that supplies your vectors and prevents the EXEC ROM from responding by blocking one of the bus control signals.

    The circuit to provide your own vectors is very easy and effectively free: GI would sell its ROMs to anybody; all you had to do was ask them to include your desired reset and interrupt vectors in your program ROM. The circuit to block the requisite bus control signal from being looped back to the EXEC ROM can be implemented with a single 7400LS series TTL chip. So it would have been no problem at all to make a cartridge that supplied its own reset and interrupt vectors and cut the EXEC ROM out of the loop completely. This would totally defeat any attempt by Mattel to lock out your cartridge by putting a special check in the EXEC.

 

    WJI

[+DZ-Jay]

1 hour ago, Walter Ives said:

    The former. The interrupt vector is not provided by the CPU. The CP-1600 interrupt system is modeled after the PDP-11's, and there it was the interrupting device that was nominally responsible for providing the interrupt vector.

    When the CP-1600 responds to an interrupt it issues an IAB ("Interrupt address to bus") cycle to request the interrupt vector from the interrupting device. It is incumbent upon the system designer to provide a mechanism for providing this vector. On the Master Component that is done by the EXEC ROM rather than the STIC chip. You understood that right: the interrupt (and reset) vectors, $1004 and $1000, are stored in the EXEC ROM, specifically in two dedicated 16-bit words that are not part of the 2K x 10 memory array and so not in the CPU's address space. The only way to access them is with an IAB.

    However, the CPU's three bus control signals don't go directly to the on-bard ROMs, they are looped through the cartridge port first. All you have to do to replace the vectors with ones of your own is put a circuit on the cartridge that supplies your vectors and prevents the EXEC ROM from responding by blocking one of the bus control signals.

    The circuit to provide your own vectors is very easy and effectively free: GI would sell its ROMs to anybody; all you had to do was ask them to include your desired reset and interrupt vectors in your program ROM. The circuit to block the requisite bus control signal from being looped back to the EXEC ROM can be implemented with a single 7400LS series TTL chip. So it would have been no problem at all to make a cartridge that supplied its own reset and interrupt vectors and cut the EXEC ROM out of the loop completely. This would totally defeat any attempt by Mattel to lock out your cartridge by putting a special check in the EXEC.

 

    WJI

Wow! Fascinating!!! I wonder if anybody here is interested in building such a circuit into their PCBs.  For starters, we could remove that silly NOP instruction breaking the PSHR sequence that saves the state (why is the EXEC concerned about avoiding non-interruptible instructions that may block the interrupt signal it is in the process of handling already???).

 

I'm sure there could be other hacks and neat tricks that could be had from this.

 

    dZ.

[Walter Ives]

57 minutes ago, DZ-Jay said:

For starters, we could remove that silly NOP instruction breaking the PSHR sequence that saves the state (why is the EXEC concerned about avoiding non-interruptible instructions that may block the interrupt signal it is in the process of handling already???).

    Because Frank Gruppuso warned Mattel not to string more than 6 store instructions in a row but didn't explain why. (For other readers: the reason was that non-interruptible instructions are also non-interruptible for DMA purposes, and the CPU had to respond to a DMA request withing a prescribed short time for every row of cards.) The reason wasn't divined until the real chip set became available, and by that time the Exec was frozen. So yeah, that silly NOP is a complete waste of a perfectly good decle and six precious CPU cycles. The code was right at the front of the EXEC listing too, where it was especially painful to look at. A front-and-center blemish on a masterpiece. A glaring pimple on the face of the Mona Lisa.

 

    WJI

Edited April 25, 2023 by Walter Ives