Why bang the hardware?

[Mclaneinc]

Here's one for the techies in here..

 

When I started to learn assembler it was like asking a chimp to design the space shuttle but I worked and worked at it until I could code boot disks, simple utils and silly stuff but nothing actually wonderful because I wasn't up to that level, but one lesson I was always taught by folk was that you never used the direct access to certain locations and always use the shadow locations. Obviously the benefit in this meant that your code SHOULD work across OS changes so I never to coin a programmers phrase from the time "banged the hardware".

 

So why did so many break that rule?

 

What are the so called benefits in doing this, does it give you more cycles thus allowing more of anything or allow for custom non standard screen modes etc because of the increased instruction capacity..

 

I was just looking through some older compilations that were found to be OSA only, just silly game loader menu's, nothing fancy like a RobC, purely a DOS disk with an autorun calling up and displaying a directory to the screen with a keyboard key scan for a letter between first and last file, not exactly rocket science, even mine and Steve's multiboot type menu went WAAAAY beyond that with sprite displays and reading in pure sectors rather than using the dos file system. The stinker in a couple of these menu's was the key scan, wasn't picked up unless OSA was in place....Why do this?

 

There's a standard key value location that's easy to read and wait for input, why do some weird key scan?

 

I know its hard to work out the workings or mind set of someone else's code so I'm more keen on why people passed shadow locations?

 

I'm keen to know as I never got to the dizzy heights of what people would call real coding, mine was for fun and I liked what I did..

[Marius]

Hi!

 

Can think of multiple reasons.

 

1) Lack of good documentation. Perhaps they did use their own found entries.

 

2) Without OS alternatives and newer machines actually existing no one did run into issues. The software worked, so nobody complained. It's like saying to someone do not this or do not that, you might get in trouble in future. It's 'pretty easy talking' afterwards, but as long as there are no new machines (back then, when only OS A and OS B existed), nobody did run into real issues.

 

3) And... perhaps people did use the wrong entry point as a mistake, but since their software worked, they did not recognize their mistake as a 'bug'...

 

4) Some people perhaps did not care at all, as long as it worked on their system.

[Mclaneinc]

All viable, I just find it odd that they sat down and learned the DOS system stuff and the like but then did some weird stuff on the more simple key scan...I understand that at that time under most machines being OSA early on that it would have seemed to be fine but this disregard went on later.

 

Also I'm not just talking OSA, there's still folk that ignored the shadow registers long in to the life of the XL and XE..

[Rybags]

Even on highend retro machines like Amiga you just have to hit the hardware.

 

It comes down to overhead of calling OS routines, not to mention that the old OSes didn't support much of the functionality anyway.

That's why MS brought out DirectX which fits in nicely with the Plug n Play philosophy.

 

On our old sub-10 Mhz beasts every cycle counts so even when the OS does support a given function it's usually better to roll your own code (e.g. the notoriously slow line-draw).

 

The "sinner" practice is jumping into undocumented spots within the OS itself, usually to save a few bytes of programming with speed a sometimes secondary benefit. Though in some cases direct references to the OS Rom were due to functions that had no user usability, like the keyboard map which some programs looked up directly in the 800 OS when Atari should have provided the vector in the first place like in the XL OS.

[flashjazzcat]

The OS keyboard handler is far from ideal if you want to capture non-standard key codes, and if space is at a premium, the temptation is to reuse the keyboard lookup table in the OS ROM with your own keyboard handler. Make assumptions about where that table is located and you run into issues.

 

It's possible to ignore the shadow registers and work directly with the hardware without causing breakage (many A8 facilities require direct writes to hardware, after all, and for the most part the hardware registers never moved from the very first A8 model till the last). I think the greater issue is making calls to undocumented OS entry points. Avery has pointed out that Mapping the Atari may be culpable in this respect, since - invaluable resource though it is - it listed too many internal OS addresses and some developers presumably misused this information.

[Mclaneinc]

Ah so some of my assumptions were correct re cycles and free mem, do things like certain custom non standard gfx modes totally require the use of non shadow / undocumented locations or can they be achieved but possibly with the loss of cycles etc?

 

The main reason for this was that I was lucky as people know to have direct free access to all the dev manuals etc and I remember the disclaimer on one say that these locations could change so use the shadow locations. To be honest the wealth of info wasted on me as most went at that point way way way over my head but I was not easy to put off.

 

I've always wondered when you see these fancy 'tricks' on the screen etc if they are do able by standard programming ways or its all hacks and corner cutting..

[Rybags]

The OS only builds the simple modes + text windows so isn't much use.

Also a game will generally want stuff in fixed locations so you don't want OS memory management deciding your screen is at $9C00 when you might want it at $3000.

 

Really, about the only thing the OS provides in common use is the disk IO (raw sectors), VBlank processing and keyboard IRQ. Most else is done by the game itself.

With others like C64 it's much the same though in the C64 case there's often a custom disk IO routine in place early on in the load process.

[sanny]

one lesson I was always taught by folk was that you never used the direct access to certain locations and always use the shadow locations.

 

The shadow registers serve one important purpose:

One cannot read the hardware registers to find out what was written to them. So to be able to restore them to their original values after you're done, you need to use the shadow registers.

 

Another nice benefit: They are only updated during the VBI. So if you were to write a new background color to the hardware register, this change would show up immediately, giving you one frame with the old bg color at the top, and the new color at the bottom. Which doesn't look nice (although it's just for a very short time, < 1 frame).

 

Sometimes you need to use the hw registers, e.g. in a DLI handler, to change the bg color at a specific beam position. This would not work using the shadow regs, since they are only updated after the whole frame has been displayed.

 

So, to summarize, "it depends". Use the shadow registers by default, and use the hw registers when needed.

 

regards,

chris

[phaeron]

I wouldn't assume that people had the official manuals at the time. When I had my Atari growing up, I had a lot of the popular books including Mapping the Atari, Compute's First Book of Graphics, and the Atari BASIC manual, but not the OS or Hardware Manuals, which were the two that actually told you what you were "supposed' to do. It's probably even safe to assume that some people didn't even have the manual for the assembler they were using (cough cough).

 

Additionally, anyone used to the Apple II would have been fine with jumping into the middle of the ROM as Apple didn't bother to declare vectors in a well defined place, instead just publishing vectors in the middle of the ROM like Atari did with the math pack. They got burnt by that later with the IIe and IIc, but worked around it by adding a 65C02 and putting in an extra ROM on slot 3 they could jump in and out of for the needed modifications.

 

The shadow registers are funny as I have seen more bugs caused by people trying to use them than not. Taking over the machine and ignoring the shadow registers is not that hard to do correctly and afterward any concerns about the OS ROM or shadow variables vanish. Programs that try to use the shadow registers, though, frequently get tripped up by the not so well advertised caveat that the shadow registers get updated in VBI if stage 2 is not skipped, which includes disk I/O. As others have said, the OS provides reasonable services for booting, but if you want to push the hardware it is very inadequate. All my 2600 ports don't even bother trying to hook into the OS, they just grab the root interrupts and ditch the OS handlers ASAP.

[+slx]

I think a lot of that could be due to poor documentation. While living in a German-speaking country, all my initial Atari literature was from the US as there was no German literature when I started on Ataris. It took some time until the ubiquitous red and white "Data Becker" books showed up on bookstore shelves. I remember browsing through "Atari Peeks & Pokes", the German equivalent to "Mapping the Atari" with some disdain as it advocated using some of those "direct" OS entries rather than documented procedures.

 

Early programmers had to find out through trial and error (or disassembling the OS), so you can't really blame them for using what worked rather than the "correct" way that was hidden in Atari internal OS documentation until Atari released it after a couple of years.

 

 

 

The shadow registers serve one important purpose:

One cannot read the hardware registers to find out what was written to them. So to be able to restore them to their original values after you're done, you need to use the shadow registers.

 

 

Very true. Shamus doesn't use them and there was no way to restore previous colors when implementing the pause screen.

[Mclaneinc]

Excellent replies chaps, even though I did have the Atari dev manuals it was over my head and even if I had smarts to understand them I would not have had the time, big old manuals they were..

 

I keep slipping into the notion of trying a bit of assembler again but so much is hazy...I'll see...

 

Again thank you for the most excellent info...Hell, I even understood a lot of it

 

Paul..

[Rybags]

Biggest positive of the shadows IMO - since most are VBlank related you get glitch-free transitions.

If you hit CHBASE during the frame for animation via charsets then you're likely to get glitches. Colours we all know about. Same with many other things.

[lbaeza]

Hi

This is an extract of the article named "Then and now The 8-bit Atari computer" by Matthew J. W Ratcliff, as it appeared on Analog Computing #59.

It explains that even code published on books made illegal calls. This could be the reason behind many "breaking the rule".

 

 

New and improved operating system.

Shortly after Atari came out with the 800XL, they released the translator disk. Several other translators have been making the rounds over the past two years as well. We should never have needed them, however. Here's why:
In the early days of the Atari, some hacker types discovered two "illegal" entry points in the system. Called EOUTCH and EGETCH in Mapping the Atari, these illegal entry points would print a single character to the screen and get a single character from the keyboard. These locations never changed throughout the life of the 800/400 systems, or during two revisions of the operating system. Because the illegal entry points were documented in the magazine, many people assumed this was a "safe place" to do a quick and dirty screen write and keyboard read.
Unfortunately, when the 800XL came out, these locations moved. Everyone pointed the finger at Atari, and blamed them for coming out with a new, "incompatible" computer. But, as anyone who's read Atari's Technical Reference guide for the 8-bit knows, these illegal entry points were never documented by Atari. Bill Wilkinson's "Insight Atari," column in Compute! showed users how to perform these functions "legally" with calls to the CIO (Central Input/Output) utility in the operating system. With the CIO and the proper setup code, you can legally perform I/O with any device on the Atari, including screen, keyboard, cassette, printer and disk.
It wasn't Atari's fault that a lot of public domain and some good copyright covered software (written by irresponsible programmers) wouldn't run on the new XL and XE machines. Atari helped bridge the gap with the translator disk (at a $10 charge), until the old code was replaced with newer and better programs.
Setting up a CIO call to do the exact equivalent of the EOUTCH and EGETCH routines only takes six lines of assembly code each. It's unfortunate that, around the time the XLs came out, Compute! brought out "Assembly Language for Beginners" using the illegal calls!

 

Is this the Bill Wilkinson article the author is referring to?

https://www.atarimagazines.com/compute/issue38/077_1_INSIGHT_ATARI.php

 

Kind regards,

 

Louis BQ

Edited May 8, 2018 by lbaeza