How much ram does the line buffer utilize and how?

[Thomas Jentzsch]

What should it do without any parameters?

[Nukey Shay]

I meant duping the CPU so that the pointer itself is not internal. But it's only 2 cycles because it IS internal. Nevermind

[ZackAttack]

treep78, your best bet would be to use a cheap FPGA and MCU instead of several ICs. The MCU could send data to the FPGA serially so you could get away with using a MCU with only a few pins. The FPGA will have to cost a few bucks, but will pay for itself via the savings on IC count and PCB size. I think this could make your $5 target feasible once the PCB cost is split across multiple units.

 

If you would like to team up on this project I could take care of the FPGA side of things and you could focus on the OS and API for the MCU.

 

Here's what I'm thinking we could make:

Background would consist of two scrollable screen buffers. Pixel data would be stored in a 12x30 byte buffer with 40x192 pixels visible on the screen. Scrolling has a resolution of 1 pixel (horizontal pixels are actually 4 screen pixels) Color data would be stored in a 16x30 byte buffer where each byte represents the color of 6x1 pixels (24x1 screen pixels)

The buffers combined would require 840bytes of MCU RAM. The FPGA would buffer a line of data at a time and signal an interrupt on the MCU when it is ready for the next line to be sent over. Now the FPGA will handle bus-stuffing the playfield registers at the appropriate time to allow for the 40pixel/7color per line background graphics. This will also leave enough time for around 6-8 additional TIA writes per line. It will be left up to the game program how to utilize those writes. During vblank there will be additional TIA writes available and some time to read controller inputs. The FPGA would also take care of the horizontal scrolling which will be way more effective than shifting bits around in the MCU, not to mention the precise TIA write timing required for the colors to scroll in sync with the pixels. Since the FPGA will signal interrupts when it needs data, the MCU will be able to maximize the time it can spend on game logic processing. The different types of interrupts can be translated in the OS to their respective API callbacks. In other words, you could specify a game code function to be called every time vblank starts!

 

I love the idea of having a C++ SDK for the 2600. It could really improve an already great game library and even open the door for distributing games as digital downloads for a small fee. Though I think at least some of the proceeds should go to this site.

[Thomas Jentzsch]

Now the FPGA will handle bus-stuffing the playfield registers at the appropriate time to allow for the 40pixel/7color per line background graphics. This will also leave enough time for around 6-8 additional TIA writes per line.

I am no hardware expert, but wouldn't the FPGA and the normal 6502 code collide on the bus then?

[ZackAttack]

The FPGA would be what's providing the normal 6502 code. The only time there will be a collision on the bus is when the FPGA intentionally overrides the data being written to the TIA registers during the bus-stuffing operation.

 

Each line will consist of 24 "STY TIA_Address" instructions (24 * 3 = 72 cycles) and 4 cycles of noop. The noops would be used to offset when the writes happen to try to keep the colors in sync with the pixels during horizontal scrolling.

[roland p]

supercat did a test project back in 2011 but, to the best of my knowledge, nothing has been done beyond that. See his topic Bus jamming experiments/issues over in the restricted Harmony Cart Development forum, it's currently the 7th topic.

batari has also tested this: "Bus stuffing" like The Graduate.

Edited September 23, 2014 by roland p

[maiki]

When you think about it, the weakest point of all "sprite-based" home console systems is that they are more or less limited by the fact the video processor cannot draw too many of them on a single scanline... Beginning with Atari 2600 up to SNES... It would be interesting to see if any king of external power could increase the sprites pixel count and still keep the high framerate...

[ScumSoft]

I've returned for a little while, not sure how much time I can spend on my hobbies though.

 

I'm back to working on my old project, rewriting the DPC+ ARM bootloader code for a more bitmap/vector based display output, and want more info into what has already been tried.

I would like access to the restricted Harmony Cart Development forum, please.

[Nukey Shay]

No way. You didn't give the secret handshake. WTF is it with secret forums anyway?? Kinda defeats the purpose as far as programming goes...I'd think.

[raindog]

Just another example of how AtariAge forums are the opposite of [stella].

[Thomas Jentzsch]

Some projects have to be done by a limited number of persons in a secret forum. For various reasons like surprises, licensing, prototypes, spamming...

[Mr SQL]

Some projects have to be done by a limited number of persons in a secret forum. For various reasons like surprises, licensing, prototypes, spamming...

I think Nukey has a great point; exploring and pushing the limits of VCS programming is exciting and fun, AND collaborative on an open forum; your points are valid too but since the two concepts aren't compatible why not keep the secret forum content secret already and stop talking about it on the open forums??

 

Kind of leads way to nah nah nah - I want to talk programming and architecture and bathe only in cool quantum fluids like liquid helium

 

Back on topic the 2.5 bytes of linebuffer RAM on the VCS have identical limitations to the much larger screen buffer RAM on the Fairchild; I wonder why no provision was made to read the contents back programmatically other than displaying on the screen - on the VES this really had to hurt with only 64 bytes of reg RAM, particularly when a good portion of the 2K screen buffer RAM couldn't even be seen on most television sets for literally falling off of the display.

[Thomas Jentzsch]

I think Nukey has a great point; exploring and pushing the limits of VCS programming is exciting and fun...

I couldn't agree more and whenever I am permitted I am doing all my coding projects completely open.

 

 

And I did not mention a secret forum.

[Thomas Jentzsch]

Just another example of how AtariAge forums are the opposite of [stella].

Nope. There were secret projects in [stella] times too, but obviously not on [stella].

[ScumSoft]

There are certain things which are proprietary to the functions of the Harmony which shouldn't be openly shared. Or sample code which might prove dangerous to use except in certain circumstances for devs, like bus stuffing.

I don't want to post a bus stuffing kernel I wrote which might smoke other VCS models/Harmony revisions. Getting source code to the Encore bootloader to adapt this project, ect should not be public.(yet)

 

So there are great reasons to have a special dev only forum, and I "need" some red key card access.

Edited November 25, 2014 by ScumSoft

[Albert]

Just another example of how AtariAge forums are the opposite of [stella].

I take offense at this. There is an enormous amount of information freely available about 2600 development (as well as development for other systems) on AtariAge, considerably more than there was on [stella]. Hardly a day goes by when someone doesn't start up a new 2600-related project. Whatever "secret" forums there are make up a minuscule percentage of the total number of development-related posts here.

 

Like Thomas said, secret projects happened in the time of [stella] as well--they simply would be discussed via email or other means instead. Private forums are just another tool available if the need suits, where specific individuals can be invited to participate in a discussion. The ability to include attachments, subscribe to the forum and specific topics, the ability to search just in that forum, and so forth, make a private forum more useful than an email chain with a whole bunch of people cc'd.

 

..Al