ARM Assembly Beginner Questions

[Just Jeff]

Good Evening,

 

If anyone could steer me in the right direction, I'd appreciate it...

 

I'd like to look into learning ARM Assembly. Does anyone have any commented code and/or tutorial they can suggest?

 

Also, is it better than DPC+ ?

Can it make in-tune music?

Does the code run mainly on the Melody board, using the Atari mainly for its registers?

Which tools do I need? Which compiler, etc.

Is ARM assembly much more difficult than 6502?

 

Thanks!

 

 

[+SpiceWare]

I'd like to look into learning ARM Assembly. Does anyone have any commented code and/or tutorial they can suggest?

 

My ARM assembly comment was tongue in cheek, hence the . I don't know of anybody who's used it for developing an Atari game - the things John Champeau and I are doing are written in 6507 assembly and C (which is compiled into ARM code).

 

 

Also, is it better than DPC+ ?

 

They're not comparable - DPC+ is a bankswitch scheme which includes a coprocessor like DPC did back in the day (sadly DPC was only ever used for Pitfall 2). As a coprocessor it speeds up 6507 routines, making it possible for the kernels to display more onscreen than the 6507 can manage on its own. Additionally DPC+ includes the ability to offload game logic to the ARM during Vertical Blank and Overscan; we've been writing this game logic using C, not ARM assembly. CDF and BUS are also bankswitch schemes with coprocessor and the ability to offload game logic to the ARM, they just have different coprocessor features than DPC+.

 

If you're wanting to offload game logic to the ARM then you'll want to use the new CDF bankswitching rather than DPC+. In DPC+ this ability was tacked on as an afterthought, so the implementation's a bit kludgy. CDF was designed from the ground up for this, plus it makes more ROM and RAM available for the ARM code.

 

The bankswitch schemes for the Harmony/Melody are written using ARM assembly because the timing is critical.

 

Can it make in-tune music?

 

You do not need to use a coprocessor to pull off in-tune music, see Stella's Stocking's menu for a most excellent example of this. However, doing it with just the 6507 leaves little time for anything else so one of the coprocessor features of DPC, DPC+, CDF, and BUS is for the generation of 3-voice music.

 

 

Does the code run mainly on the Melody board, using the Atari mainly for its registers?

 

You have to write code for both the 6507 and the ARM and coordinate the two to work together; it's rather disappointing to see people dismiss what John and I are doing as though it made things easy .

 

 

 

Which tools do I need? Which compiler, etc.

We're currently using Linaro for both ARM assembly and C compiled to ARM code.

 

 

 

Is ARM assembly much more difficult than 6502?

Unknown, as I've not learned it yet. That said, when I look at ARM assembly I can usually figure out what it's doing.

[Just Jeff]

Well that's why I couldn't find anything on it.

 

I'm not sure which way to go now.. I'm mainly interested in stuffing more into the kernel, making a game 8K or larger, with a little in tune music.

 

So I need to write in 6502 assembly and C, and somehow CDF "scheme" fits in there?

 

Thanks!

[+SpiceWare]

Since you don't know C, I suggest learning it. I found this online C tutorial that looks pretty good, even lets you code online:

[Just Jeff]

OK Thanks.. I'm working on it now. Funny.. it looks a lot like Unix/Linux scripting to me so far..

 

The guy in the cube next to me knows C and said he'd help me. The guy across from me asked "Why not use C++" I told him I think its because the age of the technology. But then he said it compiles to the same thing, I think. Do you know why it's not another version of C?

[ZackAttack]

c++ is certainly possible, but I think it would make things harder for you instead of easier and wouldn't produce anything better than you can accomplish with c. Either way you're going to find yourself avoiding the use of malloc and new.

 

Have you outlined exactly what type of game you're looking to make?

[Just Jeff]

OK. I told him something like that too- but with a whole bunch of "I thinks" in there since I didn't know. How would it be harder?

 

btw the the tutorial mentions repeatedly that C was invented to write Unix. I assume that's why I'm seeing some similarities?

 

I know its just the start but between Unix and DASM, this little bit is familiar to me already (but different):

printf("Hello, World! \n");

I think it would be helpful to see some code examples that apply to CDF so I can look at them as I go along- to put things in context. Anybody have any?

 

And.. I searched around some more and just made the connection- CDF is the result of the bus stuffing effort. Correct?

Edited December 15, 2017 by BNE Jeff

[ZackAttack]

Keep in mind that C++ is a superset of C. You can write pure C code, put it in a cpp file and call it a C++ project. C++ adds templates and classes which is what makes it more powerful. Having the object-oriented mindset that's required to take advantage of that power is just one more thing to learn. By itself it's not difficult and I'm sure you'll learn it eventually, but if you're just learning to program it may be easier to take it one step at a time. You also have to deal with the fact that embedded processors are weak and there is no OS to do all the heavy lifting for you. So managing memory and object lifetimes in c++ will definitely up the difficulty some.

 

CDF took the lessons learned from the original DPC+ driver and the BUS driver experiments to create what I would consider the next evolution of DPC+. Maybe they should call it DPC++ SpiceWare is one of the co-authors so I'm sure he could provide you more specifics.

 

I've also been working on writing a driver for the Harmony/Melody hardware which aims to allow the entire thing to be written in c/c++. Instead of queuing up several data streams for a corresponding 6507 kernel, you simply call some functions to write the different TIA registers. What's really cool about this is that you can do a lot of the display and audio processing during the same time the screen is being drawn. Leaving almost all of vblank and overscan free for the ARM processor to do gamelogic and maybe even read from the SD card. It's very much a work in progress but it currently works and I used it to make a kernel which is achieving 17 TIA writes per scanline without needing to use bus stuffing. If you share more about what you want to build I can tell you if this new driver would be a good fit or not.

[+SpiceWare]

Hmm, don't know if C++ would be useful or not

 

I suspect the overhead of the object oriented features would run into problems due to limited resources, by default the ARM code only gets 2K of RAM (you can give it more by shrinking the 4K Display Data).

 

 

 

I only post ROMs in the homebrew forum, but I post technical information as well as ROMs and Source in my blog. Do note that the CDF driver included with that source has problems with 7800s (it works OK when run from the Harmony menu, but when flashed direct to the Harmony or Melody it fails to boot on 50% of the 7800s that Al tested it on).

 

 

While attempting to fixed the CDF driver we bumped it to version 2, but Stella didn't like that, so we reverted back to V1 while we were solving the problem due to the crunch we were under for the release at PRGE (I was working on Draconian while my folks and I were driving cross country to see the Grand Canyon and attend PRGE!). Next month, once I get back to working on Atari projects, I'll be bumping the fixed CDF driver to V3 and updating Stella to work with it. The version can be seen in the debugger, I plan to have it display a warning if the buggy version of the driver is being used:

[DirtyHairy]

I am doubtful about the benefits of C++ over C in this case as well, in particular if you don't know the language well. While it is definitely possible to use C++ in an embedded context (that's what Arduino does), naive use of virtual dispatch and runtime polymorphism can exhaust memory quickly. It is still possible to use classes and templates to your advantage, but this requires a certain level of experience with the language and how the compiler implements it.

Edited December 15, 2017 by DirtyHairy

[Just Jeff]

c++ is certainly possible, but I think it would make things harder for you instead of easier and wouldn't produce anything better than you can accomplish with c. Either way you're going to find yourself avoiding the use of malloc and new.

 

Have you outlined exactly what type of game you're looking to make?

 

Port of Moon Cresta. What do you think?

[Just Jeff]

I've also been working on writing a driver for the Harmony/Melody hardware which aims to allow the entire thing to be written in c/c++. Instead of queuing up several data streams for a corresponding 6507 kernel, you simply call some functions to write the different TIA registers. What's really cool about this is that you can do a lot of the display and audio processing during the same time the screen is being drawn. Leaving almost all of vblank and overscan free for the ARM processor to do gamelogic and maybe even read from the SD card. It's very much a work in progress but it currently works and I used it to make a kernel which is achieving 17 TIA writes per scanline without needing to use bus stuffing. If you share more about what you want to build I can tell you if this new driver would be a good fit or not.

 

Doing it that way- it sounds like you could take a lot of existing games for other systems and tailor them for TIA and RIOT, etc. I assumed that capability existed already but what do I know.

 

I thought previously that I would write a 6502 game that relied on the co-processor only to store to TIA and work with RIOT- that existing code to do that could be modified and tacked on. Just learn enough C to get through that. Note- I make a lot of assumptions. Spiceware said I should learn C so I'm learning C. That's going on the resume though.

[+SpiceWare]

Port of Moon Cresta. What do you think?

 

 

I think the Draconian game kernel, with a different score kernel, would lend itself to that quite well. The Draconian kernel is one I'll be setting up for use in Spice C.