Bird's nest...

[+DZ-Jay]

On 11/8/2022 at 7:53 PM, JohnPCAE said:

I just wanted to point out that I still have two spare ACC units here gathering dust, and I've been slowly building a third one. The minimum order from JLCPCB is five circuit boards, so I have enough to build one for myself and up to four spares. Would any developers be interested in one?

 

To be honest, I would love to play with this, but as I had mentioned before, I am swamped with work and personal projects, and have almost no time left for anything else.

 

Once I clear some of these things I may be able to regroup and think about other, more fun things to play with (including the latest games from 2022 which I haven’t even had a chance to check out yet).

 

But even then … I have a backlog of unfinished projects waiting on the sidelines — there is the new version of the Intellivision Music Tracker, more track remixes, a game I was working on with my granddaughter — not to mention all the games I’ve already designed and started in the past, oh, 10 years!

 

… And there is just so much time left in our lives … I’m not getting any younger, you know. 😳

 

Still, I really want this device to succeed, and I really want to play with it (that’s the reason I was so interested in the API language extensions when you were designing them), but I just cannot dedicate any time to anything new right now. 
 

   dZ.

[carlsson]

@nanochess You might be the person everyone is looking for/at right now, given you know both assembly language and is the developer of IntyBASIC. Is it possible to create an interface / library to use the existing compiler to generate code that would utilize this ACC device? All the new instructions seem to be supported by the patched as1600, but does the compiler need to know about them in order to generate such instructions too?

[JohnPCAE]

Bear in mind the coprocessor instructions ONLY run in the ACC's memory space. It supplies 64k words as 16 4k pages. Each page is mapped to addresses $D000-$DFFF in the Inty's memory space.

[+DZ-Jay]

37 minutes ago, carlsson said:

@nanochess You might be the person everyone is looking for/at right now, given you know both assembly language and is the developer of IntyBASIC. Is it possible to create an interface / library to use the existing compiler to generate code that would utilize this ACC device? All the new instructions seem to be supported by the patched as1600, but does the compiler need to know about them in order to generate such instructions too?

I think it is possible, depending on what sort of hooks you expect in the IntyBASIC programmer interface.

 

To be honest, I haven't delve much into the facilities offered by the ACC, but if they can be accessed via assembly (and of course, they are), then we can extend IntyBASIC from the user side with either assembler macros (requiring the ASM keyword), or perhaps better using the USR command.

 

I can definitely help with this.  I'll try to try to take a few minutes this weekend to look through John's documentation on what's available, but if you have any specific ideas of what would be useful from INTYBASIC, I can look at that specifically.

 

    dZ.

[carlsson]

I haven't looked very closely, but I suppose things like opening screens, plotting characters, drawing sprites, defining custom graphics (and at what interval - are those bound to vertical blanking as well or can be changed on the fly?), how does the 40x24 overlay relate and interact with the 20x12 STIC screen in the background? Basically, primitives to use the core of the expansion. John wrote in another thread that e.g. text adventures would be a good fit for the ACC with its increased character resolution, and I suppose if expansion RAM can be accessed as well, it might be a first test case though as noted IntyBASIC isn't particularly strong at string handling.

[JohnPCAE]

The ACC doesn't care about vertical blanking: you can change sprite or character graphics any time you want. Depending on when it's drawing, they might not show up until the next frame, but there are no timing restrictions on what you do to it.

 

The 64k words it provides is shared between its functions. The beginning part of it is used for screen memory, the end part is used for sprite graphics, and anything left over can be used for coprocessor code. A good (and simple) use of its coprocessor would be for text scrolling: it's capable of scrolling text in its screen buffer many, many times faster than the Inty could do it. To use the coprocessor, the Inty would have to copy the code from its memory into the shared area at $Dxxx and then instruct the ACC to execute it.

Edited November 17, 2022 by JohnPCAE

[+nanochess]

5 hours ago, carlsson said:

@nanochess You might be the person everyone is looking for/at right now, given you know both assembly language and is the developer of IntyBASIC. Is it possible to create an interface / library to use the existing compiler to generate code that would utilize this ACC device? All the new instructions seem to be supported by the patched as1600, but does the compiler need to know about them in order to generate such instructions too?

I'm waiting to see where it goes, also currently I don't have too much time.

 

[JohnPCAE]

Would it help if I expanded the included example to include a library of standardized, generic functions?

[+BBWW]

I have no skills, everyone will attest to that. I don’t have others peoples money to toss around like a different INTV “related” venture, but some of us here would do some underwriting. We all have little time, this is a hobby for all of us. ThaT said this would be cool as hell.

[JohnPCAE]

A few things in this release:

 

1. Fixed a software bug relating to setting the color palette.

2. Minor typo fixes in the documentation.

3. Greatly expanded the included example:

  - It now includes and uses a bunch of generic functions suitable for use with something like IntyBASIC.

  - It uses what I would consider to be the correct and complete initialization sequence for a game that uses overlay video.

  - It includes an example of using the coprocessor to execute something useful (in this case, it's a function that converts hue, saturation, and luminance values to color timeslice values)

  - It includes some example code of reading key events from a USB keyboard (if you have the USB add-on that I'm working on also plugged in).

  - It's an actual tool. With a USB keyboard plugged in, it can be used for adjusting the color palette. I used it tonight to get the default palette colors a lot closer to the Intellivision's native palette. For the selected color, it prints out the four timeslice values that would be used to program that color. I chose to go with the USB route because it's a lot (a LOT) easier to read USB events than controller events. I'll leave expanding it to use the Intellivision controllers as an exercise for the reader 😉

 

 

Advanced Console Component 20221119.zip

Edited November 20, 2022 by JohnPCAE

[carlsson]

@Zendocon This is the thread you're looking for.

[Zendocon]

Nice.  Looks like I can modify jzIntv with this.  Good thing I compile the source code for my PIDE.  If I can get this working, I might wrap a few game ideas around it.

[JohnPCAE]

I updated the BOM (Bill of Materials). It's important to use HCT variants for certain chips or the colors don't come out right.

 

 

Advanced Console Component 20221126.zip

[Walter Ives]

On 7/23/2019 at 6:31 PM, JohnPCAE said:

The major reason why I can't achieve really bright colors like yellow on an Inty I is because of the 3k R24 resistor on the Inty motherboard

The high resolution graphics overlay of the original keyboard component is done by adding a luminance component to the underlying signal. I literally mean "adding," as the circuit used is in essence an analog summing circuit. As a result you don't get white on a colored background, you get "lighter background color" on a colored background. That is to say, you get light blue letters on a blue background, light green letters on a green background, etc. This is a technical/artistic compromise. To meet the FCC video standard, the RF modulator rigorously trims whatever video signal it is fed to fit in a 4.2 MHz channel. Large, sharp transitions in signal intensity have significant high frequency components well above this limit and don't transmit well. By limiting the luminance swing you get a better looking picture and more readable characters.

It is also important to note that the high-resolution overlay was intended to change the luminance component only and to not alter the phase of the color carrier. This is critical, because the NTSC bandwidth limitation only allows the color carrier to change phase slowly. If, for example, you try to put a single red pixel on a green background you won't see a red pixel, you'll only see an undefined blurry disturbance in the force.

Since you have bypassed the RF modulator this restriction doesn't affect you. From a "true emulation" point of view, however, you are operating in fantasyland, creating a video image that was impossible to attain.

The Intellivision II gave up on the high-resolution graphics overlay so it could repurpose the pin to let the system changer completely override the Master Component video.

 

On 11/6/2022 at 11:09 AM, JohnPCAE said:

 

Advanced Console Component 20221106.zip 1.87 MB · 5 downloads

You're going through a lot of effort here. One of the operational modes of the Master Component/Keyboard Component combination was to configure the Master Component to simply be a graphics display peripheral to the 6502. You might find it a LOT easier to do something similar here.

The only thing you need is a chunk of dual-port memory between your host and the Master Component. Something like the IDT7005, but you don't need anything near that fast. Reserve a block of that memory to hold "shadow STIC registers," "shadow GRAM" and "shadow BACKTAB". Write a simple CP1600 program to shovel the shadow memory into the STIC, GRAM, BACKTAB and sound chip every interrupt. You also have to shovel the interaction matrix and hand controller information back the other way. That's it; you're done. The program rivals "Hello World!" in complexity.

Now you can write your game programs in a high level language to run on the host side, with the full capabilities of the host at your disposal. By that I mean not only processing power, but everything: memory, disk drives and internet connections. All your program has to do to cause an image to appear on the display is write or read the appropriate shadow memory locations. No silly 64K program limitation for you, no sirree. No messy FIFO or co-processor instructions to mess with either. And you can connect whatever hand controllers you want to the host.

Locate the dual-port RAM at the cartridge addresses, $4000-$5FFF. 8K should be sufficient. Make it 16-bits wide so the CP1600 can copy each STIC register with a single pair of instructions for speed:

                MOV      @R4++, R0           ;read from 16-bit wide dual-port shadow RAM
                MOV      R0, @R5++           ;write to 14-bit wide STIC register

With 8K of memory you can fully unroll your loops. Even so, you probably can't copy all of GRAM in a single STIC interval. However, since the copy program is located in the dual port RAM, every game can have its own customized version that only copies what it actually needs.

If somebody complains that you are somehow cheating, you can say, "Hey, that's what the original Keyboard Component did. The only difference is that my Keyboard Component uses an ARM instead of a 6502."

[+DZ-Jay]

50 minutes ago, Walter Ives said:

The high resolution graphics overlay of the original keyboard component is done by adding a luminance component to the underlying signal. I literally mean "adding," as the circuit used is in essence an analog summing circuit. As a result you don't get white on a colored background, you get "lighter background color" on a colored background. That is to say, you get light blue letters on a blue background, light green letters on a green background, etc. This is a technical/artistic compromise. To meet the FCC video standard, the RF modulator rigorously trims whatever video signal it is fed to fit in a 4.2 MHz channel. Large, sharp transitions in signal intensity have significant high frequency components well above this limit and don't transmit well. By limiting the luminance swing you get a better looking picture and more readable characters.

 

It is also important to note that the high-resolution overlay was intended to change the luminance component only and to not alter the phase of the color carrier. This is critical, because the NTSC bandwidth limitation only allows the color carrier to change phase slowly. If, for example, you try to put a single red pixel on a green background you won't see a red pixel, you'll only see an undefined blurry disturbance in the force.

 

Since you have bypassed the RF modulator this restriction doesn't affect you. From a "true emulation" point of view, however, you are operating in fantasyland, creating a video image that was impossible to attain.

 

The Intellivision II gave up on the high-resolution graphics overlay so it could repurpose the pin to let the system changer completely override the Master Component video.

 

 

You're going through a lot of effort here. One of the operational modes of the Master Component/Keyboard Component combination was to configure the Master Component to simply be a graphics display peripheral to the 6502. You might find it a LOT easier to do something similar here.

 

The only thing you need is a chunk of dual-port memory between your host and the Master Component. Something like the IDT7005, but you don't need anything near that fast. Reserve a block of that memory to hold "shadow STIC registers," "shadow GRAM" and "shadow BACKTAB". Write a simple CP1600 program to shovel the shadow memory into the STIC, GRAM, BACKTAB and sound chip every interrupt. You also have to shovel the interaction matrix and hand controller information back the other way. That's it; you're done. The program rivals "Hello World!" in complexity.

 

Now you can write your game programs in a high level language to run on the host side, with the full capabilities of the host at your disposal. By that I mean not only processing power, but everything: memory, disk drives and internet connections. All your program has to do to cause an image to appear on the display is write or read the appropriate shadow memory locations. No silly 64K program limitation for you, no sirree. No messy FIFO or co-processor instructions to mess with either. And you can connect whatever hand controllers you want to the host.

 

Locate the dual-port RAM at the cartridge addresses, $4000-$5FFF. 8K should be sufficient. Make it 16-bits wide so the CP1600 can copy each STIC register with a single pair of instructions for speed:

 

                MOV      @R4++, R0           ;read from 16-bit wide dual-port shadow RAM
                MOV      R0, @R5++           ;write to 14-bit wide STIC register

 

With 8K of memory you can fully unroll your loops. Even so, you probably can't copy all of GRAM in a single STIC interval. However, since the copy program is located in the dual port RAM, every game can have its own customized version that only copies what it actually needs.

 

If somebody complains that you are somehow cheating, you can say, "Hey, that's what the original Keyboard Component did. The only difference is that my Keyboard Component uses an ARM instead of a 6502."

 

 

Interesting.  There is a difference, though, between this attempt and the Keyboard Component:  the latter was produced by Mattel concurrently with the console of our childhood.  If you're going to create a brand new, modern system that only uses the Master Component as a display component, then why limit the display output to the limitations of the Intellivision?  Why program for the Intellivision at all?  Perhaps go all out and write a game for iOS or a modern PC -- and if what you want is an old-school retro look, just add one of those 8-bit-ish looking filters to your renderer, like a lot of modern "retro" games do.  *shrug*

 

I believe the idea of this project is to offer enhancements on top of a standard run-of-the-mill Intellivision game running on the master component.  Of course, that sort of blurries the line between both platforms already, but I'm sure some of us can justify it more, in the same way that we do not consider maximizing ROM space beyond the 16K used by Mattel or adding on-board NVRAM to save a high-score table.

 

If perhaps the (perhaps exceedingly) subtle differences between these approaches is not clear, you may want to consider it analogous to the gradient in desirability from, say, having on your wall a poster of a painting by Picasso, a master reproduction of the same, or the actual artefact painting by the man himself.

 

     -dZ.

[JohnPCAE]

The point of the ACC is to exceed the graphical capabilities of the Master Component. From a graphical standpoint, it's a Keyboard Component on steroids. The coprocessor and parallel port are bonuses that I was able to add. The coprocessor is only possible because the CP-1600 in the Master Component uses so many NACT cycles: when there is a transition to a NACT, the CPU core that talks to the Master Component is free to execute a coprocessor instruction instead. And the parallel port is there simply because I had a couple of spare logic gate pins to support it.

[JohnPCAE]

I have a third spare unit ready for any developer who wants to play with it. I have a total of five circuit boards, which means that I can build up to five units. So far I've built four, which leaves one for me and three spares.

[Zendocon]

1 hour ago, JohnPCAE said:

I have a third spare unit ready for any developer who wants to play with it. I have a total of five circuit boards, which means that I can build up to five units. So far I've built four, which leaves one for me and three spares.

Do want!

[carlsson]

Good luck Zendocon, you'll be an "early adopter" on this one.

[JohnPCAE]

Two spares left now!

[Zendocon]

I'm always interested in tinkering with new ideas as opposed to popular ports.  This ought to be fun.

[JohnPCAE]

I'm building the 5th circuit board (which is the last one I have), but I have parts for more. So I'm tempted to order more boards. At any rate, I have two spares sitting on the table and soon a third one. Free to people interested in investigating developing for it.

[JohnPCAE]

A few updates:

 

1. Corrected a handful of characters in the built-in fonts. They had been incorrectly shifted left by a pixel.

2. Updated the silkscreen and Gerber files for the mainboard to reflect the correct chip types (e.g. 74HCT).

3. Added Appendix C to the documentation that shows all built-in font characters.

4. Added Appendix D to the documentation that explains how to load new firmware to the Raspberry Pi Pico.

 

Advanced Console Component 20221217.zip

[JohnPCAE]

I've built and tested the last board that I have, which gives me three spares. Since I have surplus parts, I've ordered another set of 5 boards. I have no idea how many of these I plan to build, but it gives me something to do. I don't plan to send all of them out for free as there is a cost to making these, but the offer to send free ones to interested developers is still out there.

Edited December 20, 2022 by JohnPCAE