Jump to content
IGNORED

Harmony tech specs/processor architecture


grafixbmp

Recommended Posts

I originally posted this at the "2600 and harmony homebrews/user written games/demo's and programs thread" topic but since that thread didn't make much since to most, noone said anything about the info I posted so I decided to do one on its own with the little research I did and see if anyone was intrested in taking this further.

 

Original post:

 

I think he has stumbled on to something here even if he didn't mean to. It seems so far that most are using the Harmony to mass load all their games onto one cart and that's a great thing. But this may be a good place to demo some of the more complexed things that the Harmony can do when the ARM processor is used to it fullest. Speaking of which, where can we find tech specs/opcodes for that NXP 70MHz ARM7TDMI-S microcontroller? I had understood that it would be possible to create future games that used that chip to exploit the 2600 to it's fullest. A thread that talks tech about what the Harmony can do at "full power" sorta speak would be just what the doctor ordered. Possibly some simple guides of how they (the ARM 7 and the 6507) can work in tandem would be cool too.

 

For starters, http://www.standardi...pdf/lpc210x.pdf

 

And here is an excerpt from http://en.wikipedia....RM_architecture

 

ARM info.txt

 

Ooo.. Got another good one

 

http://dkc1.digikey....on_NoAudio.html

 

This is suppost to help with going from traditional 8/16 bit processor programing to 32 bit ARM. There is also one with spoken audio.

Link to comment
Share on other sites

As far as rendering detailed graphics, I do like the idea of maxing out both of the player graphics. This would be great for any gauntlet type games. Or rendering out a high resolution screen that can display any type of gameplay. Possibly breaking the 3D barrier. Horizontaly scrolling games would be the best though. Even changing out the colors several times mid scanline with some intresting graphics to boot. The ARM can crunch heavy data and send it to the 6502 allowing it to shine as well. :ponder:

 

I just got through cleaning up an old 6 switch unit that one of my great friends gave me. Can't wait to get my Harmony in the mail to test this puppy out. :D

 

But back on topic, I would love to get my hands on the ARM's instruction set and figure out how both processors can work together efficiently. I am also intrigued with how the ARM processes it's opcodes. The idea of 3 pipelines working simultaneously is so cool.

Link to comment
Share on other sites

The ARM is a powerful chip, but there are limitations of how this extra power can be used. Most of the time, the ARM sits in a loop servicing requests from the Atari:

1) Wait for A12 (ROM request) 
2) Read address from bus
3) Fetch byte from ROM at address
4) Assert on data bus
5) Wait for change on address bus
6) Deassert data bus
7) Loop

Although the ARM runs much faster than the Atari, this loop takes almost all of the available processing power, particularly when bank-switching is used. To use the extra processing power, the Atari must be stalled, so that the ARM can be used for other things. There are a number of ways to stall the Atari, and the method used with the Harmony cart is to have the Atari execute code from its own RIOT RAM. When this happens the yin-yang is displayed on the screen, e.g. when loading from the SD card. What this means is that the ARM can only be used in parts of the code, where the Atari can be stalled.

 

Chris

Link to comment
Share on other sites

It would be cool to have Math functions like multiply, divide, sin, cos, etc.

Or a playfield with normal layout instead the weird setup it now has. maybe some scrolling. Auto sprite masking.

I though pitfall (2?) has some nice features which you could look at.

 

The ARM doesn't have direct access to the Atari hardware. It can only interface over the address and data lines on the cartridge port. This means that the usual TIA limitations are still there. However, it is possible to offload some of the calculation to the ARM (as is done by the Pitfall 2 DPC chip).

 

Chris

Link to comment
Share on other sites

As far as rendering detailed graphics, I do like the idea of maxing out both of the player graphics. This would be great for any gauntlet type games. Or rendering out a high resolution screen that can display any type of gameplay. Possibly breaking the 3D barrier. Horizontaly scrolling games would be the best though. Even changing out the colors several times mid scanline with some intresting graphics to boot. The ARM can crunch heavy data and send it to the 6502 allowing it to shine as well. :ponder:

 

I'm no 2600 expert but the only way to get the ARM to write to TIA would be if you halted the 6507 by writing to WSYNC. Even then (assuming the 6507 yields the address bus in that state) the writes would have to be in sync with PHI2 on the main board (not available on the cart). The other limit would be the physical access time of TIA, you can't write to it faster than it was designed for. I'm not saying you can't do it but batari has probably tested it out ;).

 

But back on topic, I would love to get my hands on the ARM's instruction set and figure out how both processors can work together efficiently. I am also intrigued with how the ARM processes it's opcodes. The idea of 3 pipelines working simultaneously is so cool.

 

ARM7 has just one pipeline with 3 stages :-

 

Fetch Load an instruction from memory.

Decode Identify the instruction to be executed.

Execute Process the instruction and write results back to the register.

 

Chapter 2 in the ARM Systems Developer Guide explains it all.

Link to comment
Share on other sites

It would be cool to have Math functions like multiply, divide, sin, cos, etc.

Or a playfield with normal layout instead the weird setup it now has. maybe some scrolling. Auto sprite masking.

I though pitfall (2?) has some nice features which you could look at.

 

The ARM doesn't have direct access to the Atari hardware. It can only interface over the address and data lines on the cartridge port. This means that the usual TIA limitations are still there. However, it is possible to offload some of the calculation to the ARM (as is done by the Pitfall 2 DPC chip).

 

Chris

That's right, I'm thinking of a Pitfall 2 approach. Like those registers that have internally a pointer that increments after you've read the register.

 

Is the ARM capable of doing multiply/divide during loop service?

Link to comment
Share on other sites

I somehow have mixed feelings about these super hightech bankswitching schemes. You could also grab an atari 800 and have your 'upgraded' version of the 2600.

 

The limitations of the stock 2600 are challenging, and force you to make creative solutions.

 

But then again, I'm using 32KB bankswitching myself with mid scanline bankswitching...

Link to comment
Share on other sites

I somehow have mixed feelings about these super hightech bankswitching schemes.

You are not alone here. :)

 

When I think of the possibilities that could be opened up by the Harmony, I think not in terms of increased CPU speed, infinite bankswitching or even DPC-type data pushing tricks, but Supercharger-esque multi-load capabilities with random access and without requiring manual intervention from the user.

 

Can't wait for Myst2600 ;)

Link to comment
Share on other sites

I really like the multi-load idea too. That was the hint of capability the SC brought to the table. With some creative SD card code, and smart data sets, it might be possible to make 2600 games that fetch game world data from that card. IMHO, that's a likely thing, just needs some work.

 

Given that, I would like to see something like ADVENTURE, with some really large rooms, more objects, but keep the simple 2600 graphics look, maybe smoothing out some flicker here and there, just because.

 

Most of the ideas I hear that involve desired boosts to the TIA, exist on the 8 bit computers! There is no reason why 2600 style games can't be done on those. The Pitfall II game hints at what we could see with the 8 bit computers.

 

In a way, it's kind of going backward, as the usual pressure on the 8 bitters is to scale them up to bigger and better things, but if they were used VCS style, the games would flat out rock.

 

The new compute power we have in Harmony is no big deal IMHO. There are going to be some nice graphics tweaks possible, but I can't see any of those really changing the character of the TIA. Some of the most recent homebrew games are flat out amazing. So we get just another round of that, with few worries over losing the flavor of it. A TIA is a TIA, and not enough of the signal lines necessary to directly drive it to, say bitmap color modes and such, are not present, leaving us with just a slow ramp of "new" things to enjoy over time. That's really a good thing longer term.

 

Just when one thinks this machine is fully exploited, somebody goes and does something, and because of how it's designed, every little bit matters in a noticeable way.

Link to comment
Share on other sites

I really like the multi-load idea too. That was the hint of capability the SC brought to the table. With some creative SD card code, and smart data sets, it might be possible to make 2600 games that fetch game world data from that card. IMHO, that's a likely thing, just needs some work.

 

Given that, I would like to see something like ADVENTURE, with some really large rooms, more objects, but keep the simple 2600 graphics look, maybe smoothing out some flicker here and there, just because.

 

Most of the ideas I hear that involve desired boosts to the TIA, exist on the 8 bit computers! There is no reason why 2600 style games can't be done on those. The Pitfall II game hints at what we could see with the 8 bit computers.

 

In a way, it's kind of going backward, as the usual pressure on the 8 bitters is to scale them up to bigger and better things, but if they were used VCS style, the games would flat out rock.

 

The new compute power we have in Harmony is no big deal IMHO. There are going to be some nice graphics tweaks possible, but I can't see any of those really changing the character of the TIA. Some of the most recent homebrew games are flat out amazing. So we get just another round of that, with few worries over losing the flavor of it. A TIA is a TIA, and not enough of the signal lines necessary to directly drive it to, say bitmap color modes and such, are not present, leaving us with just a slow ramp of "new" things to enjoy over time. That's really a good thing longer term.

 

Just when one thinks this machine is fully exploited, somebody goes and does something, and because of how it's designed, every little bit matters in a noticeable way.

 

I think you said in words what I always though. I have always fealt the heart and soul of the 2600 is the TIA and I think that is why I like the new hardware not just for its mass load of games on one card, but what it can do for game dev.

 

A 6502/6507 like chip was also used in many other game systems but that doesn't make thoes other systems 2600s. Only the TIA was and is unique to the 2600. I like its simplicity, its flexability, and its longevity. It has stood the test of time, and with this new added hardware will potentialy be worked harder that it ever has before.

 

I guess what I mean is that what the 6507 was slow in fecthing and sending of data, the harmony can help speed up by prearanging data in a way the 6502 can call in the quickest manner possible and with the use of large RAM banks in newer bankswitching designs can ast as the screen buffer Atari could have always used when needed.

 

High frame animation and smarter multisprite renderings. And like he said about larger worlds. Game saves may even be possible. Just think of the possibilities.

Edited by grafixbmp
Link to comment
Share on other sites

  • 2 months later...

Agreed. Those who wait for great things to come, will find they arrive at the best times they are needed.

 

As home brewers tinker and flex the harmony, the more unique and capable features we discover the harmony can do.

 

I like the DCP and everything that it can do but this is after all an ARM acting like a DCP and in turn looses its native abilities due to the overhead on simulating something else.

 

Why not merge the 2 ideas into one.

 

The DCP handles a particular type of bankswitching with enhanced processing.

 

The ARM is so powerful it can run part of a Nintendo DS.

 

Why not design a striped down form of the DCP which does several diffrent types of bankswitching but also allows the scheme to use the FULL control of the ARM natively which would take the place of what the emulated DCP did as extra to bankswitching thereby speeding up the processing power.

 

Many argue that the 6502 and the ARM can't comunicate but we know this is possible if done by proxy.

 

Bankswitching schemes place extra RAM in the cart that can be used for several things including data buffers.

 

The 6502 could theoretically place data requests or table data calls and drop them in the extra RAM and when the 6502 is halted for as small as a scanline, the ARM automaticaly picks up from the hault with a programers custom subroutine filling the request as RAM data which the cart already has access to in the form of extra RAM. Then when the ARM has finished its run and filled the request where the 6502 will expect to se in the exrta RAM, the 6507 picks up from where it left off except for a scanline has passed. And rehits to the WSYNC will allow subroutines to be bigger by dedicating scanline times to the full use of the ARM. They should be able to share data from the SD card as long as extra RAM is properly predefined to handle this. You could call it parallel programing rather than parallel processing. Similar in design to being able to use custom assembly in Batari basic programs.

Link to comment
Share on other sites

I'm new to 2600 programming, and just starting to understand tv timing the 2600 needs.

But as far as I understand it the arm needs precise timing to fetch data to the 2600 rom port.

so the scanline timing seems to be a little tight.

Why not putting the arm at work during vblank & overscan, while the 2600 do the minimal waiting stuff with a little routine inside its ram (so the rom port is not needed to be polled by the arm)

Then during the kernel the 2600 just fetch data from the arm to display amazing stuff, I don't know if there is a possibility to just get the datas from a defined port address and the arm just fetch datas continuously on that port, so the ram bank switching is not needed to get the datas.

but that would work for arm only games ^^

 

something like that:

lda ARMPORT

sta PF0

lda ARMPORT

sta PF1

lda ARMPORT

sta PF2

 

etc... or GRP0/GRP1

 

and fetching custom arm code into the arm could be done that way too: sta ARMCODEPORT

Edited by Orion_
Link to comment
Share on other sites

I'm new to 2600 programming, and just starting to understand tv timing the 2600 needs.

But as far as I understand it the arm needs precise timing to fetch data to the 2600 rom port.

so the scanline timing seems to be a little tight.

Why not putting the arm at work during vblank & overscan, while the 2600 do the minimal waiting stuff with a little routine inside its ram (so the rom port is not needed to be polled by the arm)

Then during the kernel the 2600 just fetch data from the arm to display amazing stuff, I don't know if there is a possibility to just get the datas from a defined port address and the arm just fetch datas continuously on that port, so the ram bank switching is not needed to get the datas.

but that would work for arm only games ^^

 

something like that:

lda ARMPORT

sta PF0

lda ARMPORT

sta PF1

lda ARMPORT

sta PF2

 

etc... or GRP0/GRP1

 

and fetching custom arm code into the arm could be done that way too: sta ARMCODEPORT

Have you seen my DPC Sprite Demo? It uses Harmony's emulation of the Pitfall 2 chip to do exactly that.

 

cd-w also did a DPC Music Demo to show how to tap into the music routines.

Edited by SpiceWare
Link to comment
Share on other sites

Reading the code snippet you wrote on the topic, it seems some part of the DPC works like stuff I explained in my post.

but for the moment, I'm beginning with 2600 programming so I will start with the basics before understanding DPC ^^

Is there any DPC tech documentation ? or do we need to look for sources like your demo to understand DPC ?

Link to comment
Share on other sites

Reading the code snippet you wrote on the topic, it seems some part of the DPC works like stuff I explained in my post.

but for the moment, I'm beginning with 2600 programming so I will start with the basics before understanding DPC ^^

Is there any DPC tech documentation ? or do we need to look for sources like your demo to understand DPC ?

I'm not aware of any DPC tech documentation, I actually downloaded the source of Stella to figure out how DPC worked.

 

That said, Stella 3.1 has been released and has support for something new that will be fully documented in the near future :ponder:

Link to comment
Share on other sites

The patent for the DPC is pretty good, but it is definitely in techno-speak.

 

It's cool seeing these code snippets because it is very reminiscent of the Chimera demos I was doing with Delicon. We called setting the pointers "seeking" the queue. The DPC has mask which allows for data to be packed tightly into the ROM. Masks are not necessary in a RAM-based architecture like Chimera (or presumably, Harmony, albeit more limited). So it was more like the player-missile-graphics in the Atari 8-bits. Various strips of RAM that you can write into. And vertical movement entails merely changing the starting index of the queue each frame.

 

BTW, depending on the kernel being used, such as interlaced text (ala Stellar Track) there was a need for queues to be set to skip alternating addresses. We were also planning to configure the auto-bit-reversal of certain queues to work better with playfield, so the inner representation would be more of a literal bitmap. I don't think the DPC is capable of that, not to mention the ARM rendering characters to the bitmap directly. Any attempt to draft a custom "Harmony Native" banking scheme should consider some of these things, if possible.

 

I'm looking forward to the docs on DPC+.

Edited by mos6507
Link to comment
Share on other sites

The patent for the DPC is pretty good, but it is definitely in techno-speak.

 

It's cool seeing these code snippets because it is very reminiscent of the Chimera demos I was doing with Delicon. We called setting the pointers "seeking" the queue. The DPC has mask which allows for data to be packed tightly into the ROM. Masks are not necessary in a RAM-based architecture like Chimera (or presumably, Harmony, albeit more limited). So it was more like the player-missile-graphics in the Atari 8-bits. Various strips of RAM that you can write into. And vertical movement entails merely changing the starting index of the queue each frame.

 

BTW, depending on the kernel being used, such as interlaced text (ala Stellar Track) there was a need for queues to be set to skip alternating addresses. We were also planning to configure the auto-bit-reversal of certain queues to work better with playfield, so the inner representation would be more of a literal bitmap. I don't think the DPC is capable of that, not to mention the ARM rendering characters to the bitmap directly. Any attempt to draft a custom "Harmony Native" banking scheme should consider some of these things, if possible.

 

I'm looking forward to the docs on DPC+.

Regular DPC did have a byte reversal queue for playfields, but it was never used in a released game. Byte reversal is one of those things that is easy for conventional hardware but not particularly for something like Harmony (so far it seems it would require a large table) so DPC on Harmony doesn't implement the reversed bytes. On DPC+, other features could potentially make it unnecessary - and we will release the current spec soon.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...