J.Derrick@newcastle.ac.uk (J. Derrick) (05/02/90)
[this message is a bit big- contains some discussion then my STE hardware findings] Whew! I've been away from the net for a bit due to work and machine problems, so I've only just caught up with the discussion about the STE and documentation for its new features. Here's my opinions: - I agree totally with Allan Pratt that blindly dissasembling the ROMS and using what you find blatently will result in hack code that is very likely to be incompatible with anything apart from the machine it came from [remember all the 1.09 stuff]. I therefore never intend to pass on shaky information such as ROM vectors [very likely to change], and TOS specifics [where I just don't know enough to comment]. I also don't want to wander into a copyright minefield. - I also agree totally that what is needed is *official data*. I would dearly love to become a developer and burn my copy of INTERNALS. Unfortunately I can't. [note I'm under Atari UK, not America]. To give credit where its due, over there Atari appears to be improving its support to earn its cash more. However, in the UK it costs 300 pounds [$500] to become a developer. I'm a student- that represents my grant for a whole term! It would take Devpac 2 and Lattice C v5 to be bundled before I could even begin to justify that sort of cost for support- all I really need is docs, I'm not a company! - I received 6 A4 sheets extra manual with my STE. I think that is unreasonable considering the changes from the ST. Okay, I got it for a bargain 260 pounds pre-release [$400]- I don't know the current situation, but there are _NO_ other docs avaliable. No Atari stuff, no third party stuff yet. I have been forced to hack. I am a software engineering student- I hate hacking; I want accurate docs, not hearsay. My thanks go to Mathew Lodge who has done a great deal to spread 'good', 'accurate' information. My pleas go to Atari for docs only, say <100 pounds [$160]- I can afford that, and still should be profitable for you. - Thanks are due to Allan Pratt for keeping up with these discssions and replying from an 'insiders' viewpoint [I hope that says what I mean]. Due to differing intrests your messages are some of the most debated, but I hope this is taken as a complement. Your time and opinions are definately valued here. With these topics firmly in mind, and armed with Mathew Lodge's posting I've updated my findings, and include them here. Thanks to all who wrote and expressed an intrest- sorry for the delay- troff'ing a thesis/exams and system problems are keeping me busy! I also have a _very_ simple test prog which displays the port values, which if I can work out how/get time may get posted to binaries. --------------------------------axe murder here-------------------------------- STE Joysticks/ROM ----------------- Please note this information is largely derived from my own findings, and is not backed up with hard Atari fact. I accept no responsibility for errors or omissions, and give the warning that serious damage could result from experimentation. Please don't blame me if your STE shorts out and expires! All details could be fatally flawed and subject to change in the future causing compatibility problems- please use only for personal experimentation and not full program devlopment. I include specifics for general information only. My opinions of disclaimers are my own. The only data Atari gives for the new connectors is the plug signals contained in the single sheet STE addendum, thus my only way forward was to look in the ROM. Looking at the system variable _sysbase [$4F2.L], the STE rom appears to have moved down to $E00000, which is bourne out by the exception vectors. My dissasembler would not look at this area, so I wrote a 68K routine to go into supervisor mode and dump the memory to disk. This uses GEMDOS Fwrite to save the rom a long word at a time. This is very inefficient, but it didn't like saving large chunks [I'm new to 68K on the STE, so there's doubtlessly a better way]. From this, the rom data lies in the range $E00000-$E31B48. My UK TOS 1.6 is on 2 EPROMS, both apparently 27C010-250, with the upper space empty. Looking through the code, it resembles the dissasembly in ST Internals, but with many improvements and additions for the new hardware. The BIOS and XBIOS trap handlers appear much the same as before, but there seems to be an extra XBIOS call $40. This seems to look at $FF8A00, and check for a bus error. Its purpose is unknown. Going through the initialsation stuff, the code is also mostly as before. Memory clearence is now faster, with a few extra writes in the loop. To support the new hardware, code has been added, notably around $E002C4. The DMA sound is initialised [$FF8900] and the tone control acessed via the microwire bus [$FF8922,4]. There seem to be a number of new system variables, for instanve look at $980 onwards. These locations come complete with text names: _VDO, _MCH, SND, _SWI. _SND is set up according to $FF9200, which after a bit of experimentation turned out to be the new joystick ports. Again this is for information only- their pupose is unknown. Inside the STE, the joystick ports are 3 74LS244 octal buffers, 1 74LS373 octal latch, and 2 NE556 dual timers. From the addendum, the ports give 4 switched sticks and 2 analog proportional sticks, or 4 paddles. I can't wait for the flight simulators complete with a proper yoke, although things like temperature measurement should be posible [watch this space!]. The timers form a simple ADC, wired as a monostable and connected to the new GLUE chip [? this is a bit uncertain without data]. They seem to be a voltage to frequency converter. I traced this much: |--------| |--------| | | +5V-----| 1M |---*---| 470R |---*---| |-----------0V |--------| | |--------| | | | 680pF | | To input via a choke----| ---*--- | | DISCHARGE THRESHOLD 556 wired as a monostable By varying the input, the duration of the timers pulse can be altered. If this was measured by a counter after a RESET or TRIGGER, the position of the stick could be determined. From Matthew Lodge's data they end up as a byte value in the following locations: Paddle 0X $FF9211 [all byte values] Paddle 0Y $FF9213 Paddle 1X $FF9215 Paddle 1Y $FF9217 After some experimentation, their detail is still sketchy. They float unconnected at around $80 [half range?] suggesting 0-255. Using a 100k pot connected to +5 and 0V varying the input voltage, strange results are obtained. From 5V to about 3.5V the value rises from around $05-$40. Below this the ports are not updated and contain garbage. Around this point the pot DC voltage mysteriously goes low- try a scope to see the 555 oscillations? By using current drive instead of voltage [connect a pot between +5V and the input] more meaningful results are gained. With a 100K pot the value varied in a log manner $05-$15. With the right value pot this may be the correct usage. Anyone have paddles for a CBM64 or 8bit Atari to look back and check? The digital standard stick inputs are a little simpler. Four sets of FIRE, UP, DOWN, LEFT, RIGHT give 20 lines. These are arranged as 12 inputs and 8 bidirectional lines. Matthew Lodge suggests all lines are bidirectional, but this may be misleading- the chips suggest 24 inputs and 8 outputs, which fits with what I have found. This arrangement allows far more than just a simple switched joystick to be connected- 6 inputs, 4 outputs and 2 analogue lines per connector. A quick note on the plug: the STE uses a special D connector, with 15 lines encased in a standard 9-way sized shell. These are fairly new, but a few firms list them [check stocks though- try Electrovalue (0784) 433603, part no. DP15HD, or Verospeed (UK firms)]. You want a 15 way high-density male D-plug and a standard 9-way hood [optional cover]. Unfortunately the case design means that the side lugs need to be hacksawed off to fit- solder the sawed plug housing together, and glue/file the hood to shape [try it- you'll understand!]. Solid core wire will fit the holes for experimentation, but use thin stuff to avoid damaging the sockets. This method is also prone to shorts and errors! The ports appear to be arranged as follows: $FF9201 [READ] $FF9202 [READ] $FF9203 [R/W] -------------- -------------- ------------- B0 - FIRE 0 B0 - RT 2 B0 - RT 0 B1 - FIRE 2 B1 - LT 2 B1 - LT 0 B1 - FIRE 1 B2 - DN 2 B2 - DN 0 B3 - FIRE 3 B3 - UP 2 B3 - UP 0 B4 - ? B4 - RT 3 B4 - RT 1 B5 - ? B5 - LT 3 B5 - LT 1 B6 - ? B6 - DN 3 B6 - DN 1 B7 - ? B7 - UP 3 B7 - UP 1 $FF9203 can be read as the other ports, but if it is written to, the '373 latch kicks in to action, and those 8 connections become outputs. If a read is subsequently performed, the lines become inputs again, although it may take 2 tries to get valid data from the port [the first reads the output states, then switches them to inputs for the next attempt]. I have not tried fitting a light pen/gun, but the input seems to be FIRE0. A logic pulser applied here alters the position registers at $FF9220 and $F9222. I've used a photodiode and amp or a sweet spot device [all in one] for other machines [BBC micro & CBM64] so this may be the correct method. Dig up those old video game light guns! [Make certain you know what you are doing though- they will require hardware mods!] If you take the STE apart, be wary of the SIMMS- mine died with vertical lines on the screen due to a bank of RAM loosening after flexing the board. A bit of gentle pressure on all the socketed compolents fixed things, with an almighty sigh of relief! This also caused a problem when upgrading to 1M. Cut thin pieces of cardboard to fit in the keyboard side of the SIMM holders to gently push them forward and prevent wobbles [any one remember the ZX81 (TIMEX 1000)!] Also REMEMBER TO TAKE STATIC PRECAUTIONS. If you don't know what/why don't do it! On the whole the STE seems very well designed, and a definate credit to ATARI. I like the hardware [the colours and the new ports are well designed], and the new TOS seems to have a few extras in addition to the obvious [I love the left mouse button for scrolling up text]. What a pity the documentation isn't out yet. Yes, I know my STE is pre-relese [260, proposed relese price 399], but I'm dying for some data, and just can't afford 300 pounds to become a developer. Are there any _good_ books out there? [what are the Compute series like?] I'd kill for a circuit diagram! Mathew Lodge has done a great job publishing what he can, dispelling a few rumours, and helping STE programmers be more accurate. Share and Enjoy, James Derrick. J.Derrick@uk.ac.newcastle [Bugged .sig follows!] | James Derrick | | Pt III Microelectronics & Software Engineering 'Don't Panic: | | University Of Newcastle Upon Tyne Computers can | | smell panic!' |
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (05/07/90)
J.Derrick@newcastle.ac.uk (J. Derrick) writes: >The BIOS and XBIOS trap handlers appear much the same as before, but there seems >to be an extra XBIOS call $40. This seems to look at $FF8A00, and check for a >bus error. Its purpose is unknown. XBIOS(64) has been there since TOS 1.2 and is used to detect the blitter status and turn it on or off. It has been documented officially. Looking at $FF8A00 in a non-blitter ST causes a bus error, while a ST with the blitter installed doesn't mind. This way, you can detect the blitter chip. >Going through the initialsation stuff, the code is also mostly as before. >Memory clearence is now faster, with a few extra writes in the loop. To support >the new hardware, code has been added, notably around $E002C4. The DMA sound is >initialised [$FF8900] and the tone control acessed via the microwire bus >[$FF8922,4]. There seem to be a number of new system variables, for instanve >look at $980 onwards. These locations come complete with text names: _VDO, >_MCH, SND, _SWI. _SND is set up according to $FF9200, which after a bit of >experimentation turned out to be the new joystick ports. Again this is for >information only- their pupose is unknown. The things you found at $980 onwards aren't new system variables. ATARI calls it the 'cookie jar', and it is used by TOS and programs to notify other programs that they were there and they have done something to the system. All cookies starting with _ are reserved for ATARI, and they use them to publish machine data to other programs (CPU type, shifter type etc.). Claus Brod