OS X 68k assembler

[JagChris]

Bruce, if you are going to do the Risc Instruction set. you should not limit the

asembler to local ram like Atari did. Some of us out here actually know how

to run code reliably out of main RAM from the GPU and we also know how to

reliably jump around in main and back and forth to and from local and main.

Let me know if you need any help.

 

If the 68K memory map is accessible from the coprocessors, then you should be able to use labels from any address, as long as you keep in mind that the risc mode uses word addresses, and any labels defined in 68K mode have to be divided by two.

 

If all you are doing is risc code without 68K code, there should be no reason why you can't ORG or RORG to any old address you want.

 

Bruce, we need a new GCC cross compiler for the Jag that encompasses the new programming techniques/bug fixes. (see below)

 

We also need a new MADMAC to do the same for assembly development on the system (see below)

 

If you know where we can find information on HOW TO build a new GCC for the Jaguar that would be great.

 

If you know where we can be pointed to to fix our MADMAC problem(see below as well), that also would be great.

 

Bug fix details follow:

 

Steve Scavone, CEO of 3D Stooges elaborates on the GPU/Main Ram hardware bug he has most recently squashed in the Jaguar:

 

The bug is one that would not allow the GPU to run code with jump/jr instructions in main ram reliably. According to the Atari at the time, the MMU (memory management unit)was the issue....though this certainly may have an affect on the problem, I think it is more related to how the MMU handles the instruction pipeline in main RAM. Its not broken, just different in main RAM.

 

The pipeline is how the instructions flow into the GPU from memory. The RISC processors grab more than one instruction per fetch. In local RAM this is not a problem. However, for some reason the pipeline seems to ignore the jump and JR instructions in some cases when running from main RAM. The story goes that the GPU can not jump across a page boundary reliably. This is now proven to be false. I have 'fixed' the GPU problem with a little trial and error coding.

 

The truth is if you remove all other processors from the bus, the GPU will run in both local and main and also allow jumps to and from either. The only trouble with that is the rest of the system is rendered useless! The only video you could have is the GPU writing directly to the line buffers and that wont be all that impressive. All sound would have to be internal to the DSP and it could never talk to the bus when the GPU was. Not at all practical. Fear not as there is a TESTED solution now.

 

So far I have a 36k program of GPU code running from main jumping all over the place across pages and all. With the source code from Brainstorm and this newfound discovery of mine, I can re write MADMAC to adhere to these rules. This would not only allow more effcient use of larger GPU code not having to any longer spend 300,000 cycles a second per 4k module in the GPU just to run it faster but it will also allow for a sensible C compiler for the main code.

 

If Atari at the time had explored further, they would have found that the Jaguar is a lot more capable than even they realized. It took me less than 2 weeks a few hours a nite to figure this out. this really could have made all the diference in the world.

 

Example: If you were blitting in 4 4k modules into the gpu every frame, thats 1,200,000 cycles a second wasted waiting for the blitter to load code in the local RAM. Yes the GPU takes some cycle hits running in main but it pales in comparison to the deady hits of running code this way. Now all you need to do is load a compact renderer ONCE into local RAM and simply call it when needed. All the translation and all can be efficiently done in main.

 

The 68k is still needed however, to assist the GPU in jumping between main and local RAM. I hope to discover a fix for this as well. I think I may already have too. Even if not the 68k is asleep except for a few cycles to re-aim and re-start the GPU, then its right back to bed, like it should have been! Experiments to follow!

 

Sincerely,

 

Steve Scavone,

 

CEO

Edited July 23, 2007 by JagChris

[Bruce Tomlin]

Bruce, we need a new GCC cross compiler for the Jag that encompasses the new programming techniques/bug fixes. (see below)

 

We also need a new MADMAC to do the same for assembly development on the system (see below)

 

If you know where we can find information on HOW TO build a new GCC for the Jaguar that would be great.

 

If you know where we can be pointed to to fix our MADMAC problem(see below as well), that also would be great.

HUH?

 

You seem to have mistaken me for an actual Jaguar programmer. Or even someone who has the faintest clue of what it takes to program the Jaguar. Or who even cares about programming the Jaguar at all. (I only added Tom and Jerry because it was requested and easily done.)

 

All I did was implement a particular instruction set in an assembler. I don't even have any Jaguar code to test it with, and have been asking anyone (even those encouraged me to add Tom and Jerry) to try it out and tell me what needs to be done with it to be useful, but no one has. (And I should add "in terms that a Jaguar outsider can understand", not the heavily jargoned dump you pasted above.)

 

And just who is this "we" you mention anyhow? Why is any company with a CEO trying to do anything with a console that has been obsolete for more than a decade, much less a failed obsolete console? Where's the money in that? Like the IRS says, if you aren't making money from it, it's not a business loss, it's a hobby.

 

With the source code from Brainstorm and this newfound discovery of mine, I can re write MADMAC to adhere to these rules.

That's interesting... so the source code to MADMAC has been found? Where can it be downloaded? And if someone is hoarding the source, I can tell you right now that the only sure way to get it updated is to release it to the wild.

 

EDIT: after checking around, it seems that this Brainstorm company is where it originally came from, and they seem to have no interest in releasing the code. So the phrase "rewrite MADMAC" is about as realistic as "Harry Potter".

Edited July 25, 2007 by Bruce Tomlin

[JagChris]

Hi Bruce. Sorry to load all that on you.

 

I understood you aren't a Jaguar programmer. However, you know how to build Assemblers.

 

My request was if you could point the community in the right direction of where for one of us to learn to do the same so MADMAC can be rebuilt. And if you know where on the net we can find any information on how/what/where of machine descriptors, someone could possibly create a new GCC for the Jaguar.

 

Steve Scavone's company is programming professionally for things outside the Jaguar.

 

I included all the 'Jargon' just to give you an idea of how the old assembler Atari did was geared to 'flip' code in and out of the 4k gpu cache and had no idea how to get the gpu to read/write/jump around in main like can be done now.

 

Anyways, sorry about dumping all that on you.

[Bruce Tomlin]

First of all, I didn't realize that MADMAC also did DSP stuff. I knew it did 68000 and 6502 (from seeing 7800 developer documentation), so I guess it's not too surprising to see the DSP stuff in there.

 

But the thing that you have to keep in mind is that RISC assemblers can be much more complicated than what I've got. Many of them try to keep track of delay slots and hide them from the programmer. (I know that Intel's IXP 1200 microengine assembler does this.) Some of them (like you describe MADMAC doing) keep track of multiple banks/pages of code. Fortunately I seem to recall noticing in the Tom and Jerry docs that the assembler wasn't responsible for tracking delay slots.

 

Even having the smallest addressible memory unit not be a byte, like the Jag DSPs do, makes things more compilcated.

 

Another thing to remember is that outside of the CPU instruction set, there is basically no standard on how macros and other assembler-specific features should be implemented. There's no way that I could hope to be compatible with unchanged MADMAC source that takes advantage of any of these. Certainly there's no way I'm going to do that for free on my own time. You guys will have to be willing change your source code if you want to be free from MADMAC.

 

And I have no clue what MADMAC does that is such a problem with the DSPs, why it does it that way, why it's a problem, or what needs to be done. For all I know, I won't have those problems because I don't know to put in the restrictions that MADMAC does. I don't even know how the Jag dev toolchains put things together. Sure, there's this DSP code, but where does it go? Does it get thrown into the 68K code as a bunch of blobs? Does it need to go through a linker like the 68K code does?

 

 

As for getting a GCC cross-compiler up and running, that's something that I've never done, though I am considering it for Sega Genesis work... which is where you should be looking for a 68000 GCC toolchain. It's not like the 68000 is a custom Atari chip or anything, you know.

[JagChris]

OK. I'm just barely learning this stuff. so I may be wrong on the details I didn't quote.

 

I'm not asking you to build us an Assembler. What I would like to know is where can we go to learn to BUILD OUR OWN? Is there documentation on the net? My google searches have turned up nothing concrete. Same with "machine descriptors'.

 

And as for the GCC. We already have one that comes with the tools that uses the 68k. We want to create a new one which targets the RISCs. Do you know where we can go to learn about Machine Descriptors?

[Bruce Tomlin]

And as for the GCC. We already have one that comes with the tools that uses the 68k. We want to create a new one which targets the RISCs. Do you know where we can go to learn about Machine Descriptors?

You're not just barking up the wrong tree, you're barking up the wrong forest. Try looking around for GCC implementor mailing lists on gnu.org or somewhere like that.

[JagChris]

And as for the GCC. We already have one that comes with the tools that uses the 68k. We want to create a new one which targets the RISCs. Do you know where we can go to learn about Machine Descriptors?

You're not just barking up the wrong tree, you're barking up the wrong forest. Try looking around for GCC implementor mailing lists on gnu.org or somewhere like that.

 

 

Ok Bruce.Thanks for your time!

Edited July 28, 2007 by JagChris

[JagChris]

doubble post!

Edited July 28, 2007 by JagChris

[Pu7o]

EDIT: I've been trying forever to get binutils to compile for m68k and it just doesn't want to happen.

 

 

I think the problem was that he didn't want to deal with the gas syntax. And I don't blame him. It was created for the purpose of making a portable C compiler, not for being true to the chip maker's assembler syntax.

 

Ah, be a good boy and go bitch around somewhere else, will you please ?

 

No, in this case Bruce is right on the money. I don't like the syntax and would rather use standard Motorola syntax, since it's what I'm used to. Not everything said in a negative context is bitching. The fact that it gave me trouble when I was compiling it was just the final straw that convinced me to not use gas.

Actually, GAS has a flag (-M; aka MRI mode) that allows one to use the standard motorola syntax.

[Bruce Tomlin]

At work the other day, I spotted the makefiles for a linux boot built as a binary. So I've been trying to get a Sega Genesis demo program running with gcc, and I got a lot of gas (burp) yesterday. Sure, there's that -M thing, but it was apparently meant for people trying to convert over from some obsolete assembler, and I couldn't find it documented very well anywhere.

 

What I found was that if you don't mind putting % signs before all register names and "." before all pseudo-ops, gas-m68k will indeed accept standard Motorola mnemonics. It's a little ugly, but nowhere near as ugly as the MIT/AT&T syntax, which is about as "universal" as Esperanto, with a similar number of people who are fulent.

 

Making a linker script that would generate a usable binary was another matter entirely, as was getting a usable cross-compiler. Apparently m68k isn't supported by the latest binutils, which is needed by the latest gcc, and COFF isn't supported either (used by most of the examples I've found), so I downloaded one pre-built for OS X. GCC 3.4.4, binutils 2.15, ELF object... and after getting everything else mostly working, I found out that its libc was built for 68020. So I manually added a couple of necessary library calls.

 

I've learned more about ld linker scripts than anyone should ever have to know, and I think I'm still a 2 out of 10 when it comes to understanding it. But late last night I finally got a binary that could initialize .data properly, using ELF format object files, and will eventually post the info to the appropriate places.

[JagChris]

At work the other day, I spotted the makefiles for a linux boot built as a binary. So I've been trying to get a Sega Genesis demo program running with gcc, and I got a lot of gas (burp) yesterday. Sure, there's that -M thing, but it was apparently meant for people trying to convert over from some obsolete assembler, and I couldn't find it documented very well anywhere.

 

What I found was that if you don't mind putting % signs before all register names and "." before all pseudo-ops, gas-m68k will indeed accept standard Motorola mnemonics. It's a little ugly, but nowhere near as ugly as the MIT/AT&T syntax, which is about as "universal" as Esperanto, with a similar number of people who are fulent.

 

Making a linker script that would generate a usable binary was another matter entirely, as was getting a usable cross-compiler. Apparently m68k isn't supported by the latest binutils, which is needed by the latest gcc, and COFF isn't supported either (used by most of the examples I've found), so I downloaded one pre-built for OS X. GCC 3.4.4, binutils 2.15, ELF object... and after getting everything else mostly working, I found out that its libc was built for 68020. So I manually added a couple of necessary library calls.

 

I've learned more about ld linker scripts than anyone should ever have to know, and I think I'm still a 2 out of 10 when it comes to understanding it. But late last night I finally got a binary that could initialize .data properly, using ELF format object files, and will eventually post the info to the appropriate places.

 

Hey Bruce, wake up! Someone's trying to get ahold of you regarding your assembler! Check your emails!