Omnivore, the Atari 8-bit Binary Editor

[xxl]

I understand that you should not use undocumented possibilities of ANTIC and GTIA also?

[Fox-1 / mnx]

The CPU is compliant, it's the programmers who are not.

 

You summed it up nicely but no need to explain.

 

We have different opinions about the word "complaint". Coders on 6502c write code that runs on a 6502c. If a "complaint" CPU isn't able to run this 6502c code, well, it's just not complaint. The code does exactly what the programmer intended to accomplish on an Atari with a stock 6502c so there's no reason to complain that it shows different behavior on a non-6502c CPU. A 65c816 emulates a 6502, not a 6502c, which is very close, but not exactly the same thing.

 

Whether it's annoying or not that illegal opcodes are used is another chapter but you should never blame a coder that his code won't run on anything else than is was designed for. If it was to obscure his code, well, than that was his intention. If his goal was to exclude non-stock Atari's, he succeeded.

 

Who is to blame if I fill up my car with diesel, while it requires petrol? These are both flammable fluids, used with combustion engines, and both come from the same source, yet they are not compatible.

[Marius]

Although I tend to agree with Fox-1, I see a similar thing between OS A/B and the succeeding XL OS.

 

If the coders would have followed atari's official guides, and sticked to the documented OS vectors, there would not have been compatibility issues between the OS versions. So yes, here it is indeed coders to blame.

 

Of course... software written for Atari 400 and 800 is good for that machine, and was not intend to be written for upcoming new atari models. So you could also here say: why blame coders for their software not being compatible on XL/XE models, since it was written for OS A / B. I disagree on this, since they wrote software for atari 8bit, and so they should have followed atari's official guidelines.

 

If Kyle22 is right about what he wrote about the illegal instructions (He states that even designers of the chip did discourage use of the illegal opcode), I see a certain similarity here.

 

For me -personal- it is not an interesting matter, since I do not want to change the 6502 in my atari. So that is why it is not important for me whether software uses illegal opcodes or not. As long as it runs on my atari 8bit, I'm completely fine with it.

[Marius]

I understand that you should not use undocumented possibilities of ANTIC and GTIA also?

 

There is a difference between undocumented features, and using features that the designers do discourage you to use them.

If that last thing is true...

[Kyle22]

I understand that you should not use undocumented possibilities of ANTIC and GTIA also?

Is there a new ANTIC and GTIA replacement that we don't know about? If you're thinking of VBXE, remember that it keeps the original ANTIC.

 

That arguement has nothing to do with using opcodes that the original designers of the CPU said not to use.

[Kyle22]

 

. . . A 65c816 emulates a 6502, not a 6502c, which is very close, but not exactly the same thing. . . .

It is only called "Emulation Mode" by WDC. Bad choice of names. It *IS* a 65 series processor, a direct descendant of the 6502. The 816 was designed by Bill Mensch, one of the original designers of the 6502.

 

A 6502 and a 6502c run the exact same opcodes, it is only the physical pinout that is different.

[playermissile]

And, on a related note: I'll soon have a 65816 disassembler in Omnivore. Probably not for the next version (which will be up in the next few days) but hopefully the one after that.

[xxl]

Is there a new ANTIC and GTIA replacement that we don't know about? If you're thinking of VBXE, remember that it keeps the original ANTIC.

 

VBXE is addon, not replacment of GTIA. thanks this programs uses undocumented GTIA feature works... maybe if you use 16 bit cpu as addon not replacment atari programs will work right?

if you ever created a replacement ANTIC which will not be compatible with the original ANTIC (such as 16-bit 816 is not fully compatible with the 6502c) also will complain that developers should write programs so that work on this crippled version?

[Fox-1 / mnx]

A 6502 and a 6502c run the exact same opcodes, it is only the physical pinout that is different.

 

I'll re-word what I meant: The default emulation mode of a 65c816 (the 6502 emulation mode) is not the same thing as a real 6502c. (We wouldn't have this conversation if it was).

 

 

Marius:

 

OS-A vs. OS-B is a bit of a different matter. The O.S. is basically just software. It just happens to be on ROM. Issues can be solved by just using another ROM version (externally loaded or changing (EP)ROM. CPU incompatibility is a core issue.

 

 

xxl:

 

>maybe if you use 16 bit cpu as addon not replacment atari programs will work right?

 

Even I would be interested if it was possible to use a 65c816 as a useful slave for the 6502c but as long I'll have to give up the stock 6502c it's a no-go for me.

Edited February 29, 2016 by Fox-1 / mnx

[Kyle22]

 

I'll re-word what I meant: The default emulation mode of a 65c816 (the 6502 emulation mode) is not the same thing as a real 6502c. (We wouldn't have this conversation if it was).

 

 

Marius:

 

OS-A vs. OS-B is a bit of a different matter. The O.S. is basically just software. It just happens to be on ROM. Issues can be solved by just using another ROM version (externally loaded or changing (EP)ROM. CPU incompatibility is a core issue.

 

 

xxl:

 

>maybe if you use 16 bit cpu as addon not replacment atari programs will work right?

 

Even I would be interested if it was possible to use a 65c816 as a useful slave for the 6502c but as long I'll have to give up the stock 6502c it's a no-go for me.

 

We wouldn't be having this conversation if the programmers would learn the proper use of opcodes. Maybe they are afraid to learn the 816?

 

xxl made a nice little demo for the GTIA speaker using illegal opcodes. Phaeron was kind enough to make a small patch to fix it: http://atariage.com/forums/topic/212810-tritone-gtia-beeper-engine/page-5?do=findComment&comment=3445382

 

It would have been so much better if it was written correctly in the first place.

 

OS-A and OS-B (and 1200XL and later XL/XE OS) are very similar issues. The programmer could have used the published entry points that Atari provided, but chose to use non-published entry points that were subject to change. Same with the illegal coders, they use opcodes that are subject to change with newer processors.

 

When Apple released the IIgs, they had very little problems with incompatible software. Why? Because the programmers avoided illegal opcodes.

 

There are a few different upgrades coming to market that include an 816 chip. Why continue to write software to alienate the purchasers of such upgrades.

This kind of attitude will destroy the Atari community by hurting the sales of the new products.

 

We need just the opposite to happen. Some of the brilliant coders need to learn 816 code and make some "killer app" that will boost sales of these new hardware upgrades.

The more 816's that are out there, the more software will be written. People will then begin to appreciate the power of the 816. That would benefit the entire community.

[Fox-1 / mnx]

 

We wouldn't be having this conversation if the programmers would learn the proper use of opcodes. Maybe they are afraid to learn the 816?

 

Did it ever occur to you people don't want to code 16 bit? The people who think the yellowish/brown or grey plastic casing is what makes it an Atari 8-bit probably don't care that much as long as it runs their software. And they are right.

 

But it's a nice gadget for the people with a special interest in the 65c816, and they are also right.

 

If I look at myself, I'm only interested in programming the 6502. You know, 8 bit code, that I can run on my stock XL's or XE's. I have no need for a 65c816. Atari never released a model with that CPU either so I don't have to take that CPU into account to make my code compatible with it.

 

Oh wait... I can run my 6502 code faster because the 816 can be clocked higher? Oh, wait some more... if I want to run it faster I'll start up Altirra. True, this is not a real Atari, as is yours with a 65c816.

 

No, I don't hate the 65c816 at all. In fact, the projects, and everything that comes with, it are very interesting and everyone who thinks he may benefit from it should consider it, but the way you put it is like everyone should adapt to it because it's better and because it's available, which is subjective at first and for the wrong reasons at second.

 

 

>

>There are a few different upgrades coming to market that include an 816 chip. Why continue to write software to alienate the purchasers of such upgrades.

>

 

65c816 Users are the ones who alienate themselves, be it by choice or not. It's just a matter of time until someone develops a plug-in CPU, bases on a propeller-like CPU, that perfectly emulates both a 6502c and 65c816 but at an internal xxx-MHz clock speed, putting all 65c816 CPU set-ups to shame. Will I/we have a deja vu when it arrives?

Edited February 29, 2016 by Fox-1 / mnx

[Kyle22]

You are not "coding 16 bit" or "coding 8 bit" It's all the same. LDA #$0 is still LDA #$0 in either mode. Read (and seriously study) this: http://www.umich.edu/~archive//atari/8bit/Newitems/notes816.txt

 

I know it's long, but please take some time and read it. John Harris can explain the 816 much better than I can.

 

Edit: There are many good code examples in that link

Edited February 29, 2016 by Kyle22

[Fox-1 / mnx]

You are not "coding 16 bit" or "coding 8 bit" It's all the same. LDA #$0 is still LDA #$0 in either mode. Read (and seriously study) this: http://www.umich.edu/~archive//atari/8bit/Newitems/notes816.txt

 

I know it's long, but please take some time and read it. John Harris can explain the 816 much better than I can.

 

Edit: There are many good code examples in that link

 

No need to explain. Ever came across this? -> http://mixinc.net/atari/mae.htm

It's my site...

 

I can code on both the 6502 and the 65c816 as well but that doesn't mean I prefer the 816 over the 02. From a coders point of view, if you just code in 8 bit, there's no advantage in using the 816 as it never jumps out of the default 02 emulation mode. If my code uses nothing but the official opcodes there's nothing to stop you from running it on your 65c816.

 

If, however, I choose to use undocumented opcodes for whatever reason, than that's my choice. I'll make sure the assembled code runs on the platform it was made for and that's it. If I want to protect my code by excluding anything that's not the real deal (like emulators or non-stock CPU's) then that's my decision. If you can't run it the way you want it to run, just don't use it.

 

Despite the above is just an exaggerated example, it is true. You can't tell coders they should code to "your" standards while that standard isn't even part of Atari at all. You may ask/bribe/beg them to do so but don't say "you'll have to" and especially not "you're doing it wrong". After all, you're asking them for compatibility for a minority of Atari users. Yes, a minority, because I'm sure there will be much more users without an 816 in use than there are with.

 

And also... I have multiple Atari 8-bits so I should install an 816 in all of them to "comply" to the "new standard" ? Don't think so...

 

And at last, a fact... this whole conversation is about compatibility for less than 1% of the software that is around. If you can't live without the 1%, just make sure to keep a stock Atari around :-)

[Kyle22]

All I am asking is: Please write code that works on everything. I saw your MAE stuff (after I posted the last message). I did not mean to say that you or anyone in particular is ignorant of the 816's advantages. By the way, does anyone know where to find MAE12.ARC? There's a problem with pigwa.

 

Anwhow, please be nice to all of us and write compatible code. If you include an init routine that detects an 816, then you can write code that makes everyone happy.

Those with a 6502 get illegal 6502 code, those with an 816 get 816 code. This would only be necessary in certain parts of the program.

 

I hope I made a point with everyone about the 816. The 816 is in our future. Let's embrace the 816 rather than fight against it, or say "It's not true Atari".

 

Many fine people have spent their own time and money to bring 816 upgrades to us. Let's support them. This will improve the Community in the long run. Think about it.

[snicklin]

I wish Bill Mensch would make a new 65c816 which supports the undocumented features of the 6502.

 

Then I wouldn't have to read this argument which pops up in every 10th thread on AA.

[gozar]

Didn't Bill say something about not using the undocumented opcodes in his Antic interview?

 

 

Sent from my iPhone using Tapatalk

[Fox-1 / mnx]

I wish Bill Mensch would make a new 65c816 which supports the undocumented features of the 6502.

 

That would be a nice, and wishful thinking...

 

 

Then I wouldn't have to read this argument which pops up in every 10th thread on AA.

 

There's some truth in that. This isn't even a 65c816 topic. Just related in some way. I'm outta here...

[playermissile]

Speaking of a topic: I've got Antic mode E bitmap visualization ready to go. Will get a new version out in the next few days. I'm going to demo it at the San Leandro Computer Club meeting tomorrow (well, probably today as you read this: Tuesday Mar 1), so if you're in the SF Bay Area, stop by: http://slcc.bdgeorge.com/

Edited March 1, 2016 by playermissile

[Marius]

Back on topic:

 

Today I downloaded 0.9.0 of this amazing piece of software (Mac OS X) ...

 

I was under the impression that it was at this time possible to import files to an existing ATR, but I can't find how.

Isn't this supported yet?

[danwinslow]

Good lord, are you guys arguing about opcodes again...this is really getting old.

 

And Oh, Nice job, OP. I like the editor.

[Heaven/TQA]

The CPU is compliant, it's the programmers who are not.

 

When the 6502 was first designed, there were certain opcodes that were unused. The designers did not publish them as valid opcodes. Later on people found that a few of them work, and can save a byte or two here and there in their code. That code works on the 6502, but not on the improved 65C02, which treats invalid opcodes as NOPs.

 

Along comes the 65c802 and 65c816 chips that are completely compatible with the 6502, but have more instructions (opcodes) to choose from. All 256 opcodes have a meaning on these chips, so those invalid opcodes now do something completely different than the programmer intended.

 

That's why the use of undefined, undocumented, invalid, illegal (there are many names) opcodes was discouraged by the original chip designers. They were reserved for future expansion from the very beginning.

 

No software published by Atari (or any major software house) used these illegals. The 65c816 will run all Atari software just as the 6502 did.

Edit: with very few exceptions.

 

The Demo-scene is where you normally find the use of these illegal opcodes. The coders claim they are necessary for speed, but that is usually not the case. They have gotten in the habit of using as many illegals as possible in an attempt to obfuscate their code to make it difficult for those with disassemblers.

 

If they would only run a simple test (just a few lines of code) to determine the CPU type, then they could write demos that also run on the 816, and have lots of new (and valid) opcodes to use. In other words: If it's a 6502, then use illegals (if you must), but if it's an 816, then use the new and more efficient instructions to make your demo better and faster than ever. The block move instructions alone can save many bytes of code and many CPU cycles.

 

To learn more about the 816, read the link in my post here: http://atariage.com/forums/topic/249405-new-4mb-ram-expansion/page-4?do=findComment&comment=3453397

 

 

appologies for being an asshole...

 

appologies of using undocumented opcodes just for saving some bytes here and there... (you will see the difference in few weeks... ah. sorry... it will not run anyway on 65816... and better... not on HDD....)

 

if you are so clever in doing things with 6502/65816 go for it...

 

Heaven "asshole" 6502

Edited March 1, 2016 by Heaven/TQA

[playermissile]

Back on topic:

 

Today I downloaded 0.9.0 of this amazing piece of software (Mac OS X) ...

 

I was under the impression that it was at this time possible to import files to an existing ATR, but I can't find how.

Isn't this supported yet?

 

Thanks, glad you like it!

 

Currently, it can display files in an ATR (Atari DOS or SpartaDOS) and you can also edit them in a view that hides all the next-sector metadata, but can't add files to the image yet. I do plan on adding that capability, but it's a bit farther down the ol' roadmap. Dan Boris has a program that does that if you're on windows: http://www.atarihq.com/danb/atari8bit.shtml

Edited March 1, 2016 by playermissile

[Fox-1 / mnx]

This may not be the main goal of the tool but would it be possible, and are you interested, to support Black Box formatted media?

 

It's a proprietary format which isn't compatible with any MS/Apple/*nix format but once you've read the partition table(s) you know where each sequential disk image starts and ends while the image itself can be treated as an ATR image (more or less).

[playermissile]

This may not be the main goal of the tool but would it be possible, and are you interested, to support Black Box formatted media?

 

It's a proprietary format which isn't compatible with any MS/Apple/*nix format but once you've read the partition table(s) you know where each sequential disk image starts and ends while the image itself can be treated as an ATR image (more or less).

 

Does proprietary = not documented? Is it Atari 8-bit specific? To support it, I'd need to see documentation of the format, or better yet: a python implementation to decode it. I must admit that it doesn't seem like something that would be very high on my list because I've never run across it before. But with help from others who have a need for it, I'd be happy to include it.

 

Omnivore is free software and open source, soooo... If you happened to want to contribute something, I'd be happy to take it! You can check out my github repo here: https://github.com/robmcmullen/omnivore

[Fox-1 / mnx]

Unfortunately, the format is undocumented but isn't that complicated. It's a table with info where each image starts, followed by the length (in 256K sectors). This is repeated 96 times (=max entries per partition list) but it's possible to have multiple partition lists on the same physical disk/memory-card/whatever-media-you-use.

 

I just don't know exactly how the data is stored because I just never looked into it deep enough but if I can find the time I can figure it out. Or maybe someone else already did. Have to ask around for that,.

 

I think the issue will be that the media has to be accessed as raw data and the O.S. may absolutely not write anything of it's own data to it. I have no idea how difficult that part is, or if it's possible at all.