ijor

The "best" way depends on the hardware you have and how the disks are formatted. Most people use a SIO2PC cable that connects the A8 to the PC through the serial port. Or a 1050-2PC cable that connects the drive directly to the PC. The cables are easy to build by yourself or can be bought for a very reasonable price. The advantadge of this method is that you can read any disk. The minus is that is somewhat slow compated to other methods. If you have a PC 5.25 drive you can read "some" disks directly on your PC, which is way much faster than using a SIO2PC or 1050-2-PC cable. With software that is widely available, you can normally read double or enhanced density disks, either single or double sided. But you normally can't read the flippy side, it depends on exactly which 5.25 drive you have. Reading single density disks is much more complicated, some PCs can others cannot. If in addition to the PC 5.25 drive, you have a Catweasel or a Copy II PC Option Board; then the single density issue is solved. The flippy side is not because it depends on the drive, not on the controller.

Hmm, it shouldn't be any difference at all between an US or European 1050 drive. Or you mean a XF-551 ? I understand that many XF-551 released in Europe have mechanisms that can't read the flippy side. But that should be the only possible difference. Many protections fail to load if the drive rotation speed is not accurate. But this can be easily adjusted.

Furthermore, there are subnorms both for PAL and NTSC. And if the TV and the equipment don't match in the subnorm, you might also get a black and white display. Plus if using RF (not composite), you might get not sound. There two or thre NTSC variants I think which I don't remember the exact name, and about half a dozen PAL subnorms (PAL, PAL-B,PAL-N,PAL-M,PAL-I).

I'm not arguing because I don't know the specs of the 1084, just asking ... You get color with your 1084S using a PAL output, or just at 50 Hz (with your modded PAL Antic)? One thing is to be able to sync to both rates (50-60Hz). Another thing is to be dual-norm (PAL/NTSC). If you using your US A8 with a PAL Antic, you are just changing the refresh rate, but the video signal will still be NTSC.

Not at all. You can perfectly use a TV with any refresh rate disregarding the line frequency. I guess that originally, when the TV standards were designed, there was a relation. But you can use an european TV with a 60 hz line frequency and the refresh rate will still be 50 Hz. Or viceversa. Or if the TV can sync to both refresh rates, then it will use whatever the computer will send. You might need a transformer, but transformers adapt the voltage, not the line frequency. And virtually no equipment has problems when used with the "wrong" line frequency.

I second the idea of a chip problem. This does NOT look like a mechanical problem. If Track zero sensor, or stepper, or spin-motor is failing, then the symptoms would be different. If the problem is mechanical, you still get the "normal boot" with the busy led being turned on for a second. Motor might not turn on, stepper might not move, but if the busy led turns off too quickly (or doesn't turn on at all) then the problem is electronic or electric, not mechanic.

I agree with Bryan that is not related to the belt. Furthermore, it doesn't seem to be related to any mechanic component at all. Looks like some failure in the main digital electronics. Might be CPU, RIOT, ROM, etc. When the 1050 boots it moves the head inwards and then outwards. If the head doesn't move at all you might think the problem is related to the stepper, but I don't think so. If the 1050 finds some kind of failure it will blink the busy light. In your case it doesn't. This means that either it didn't find any failure, or it failed in such a way (the micro locked up) that it can't give any feedback. But if it didn't find any failure (not every failure can be detected by the 1050 CPU), it should communicate with the computer. And then you would get a BOOT ERROR and not the MemoPad. Might be, of course, some kind of power problem as well.

Yes, .ST and .MSA are standard formats for all ST emulators. See http://mysite.freeserve.com/x3peri_mental/STIMAGE2.htm for links and descriptions of several tools. Makedisk is probably the most popular tool. It normally works well enough under Win'98 but it usually safer under plain DOS. There is a version for ST as well. Sorry, no idea about Mac tools. Not sure about a download site specific for ST applications. There was such a place but I can't find the URL right now. Check Steem's Link page or AtariLegend Link's pages.

You are possibly right. I have no idea how many games check the GTIA PAL flag. Neither I was talking about your specific case. It might be worse for the opposite case (putting an NTSC Antic on a PAL machine). I suppose you are using mostly cracked releases. Because several protections are likely to break when using an unmatched Antic/Gtia pair. But again, I'm not so familiar with Euro protections and releases and this might be more of a problem with US releases (that I understand you load in a different machine). Changing the GTIA chip is not that simple. I'm not sure and probably Bryan could tell us the details. But I understand that you need to change the rest of the encoding/modulation logic for swapping the GTIA.

No, it uses fixed values disregarding the PAL flag. They are $28 for standard peripherals and $5CC for the tape. And they will indeed produce slightly different bit rates at PAL vs. NTSC. The difference between the main PAL/NTSC clock is too small, impossible to compensate with a different value at the Pokey divisor. The PAL flag is used to change timings that depend on the 50/60 Hz frame rate, not on the tiny difference of the main clock.

Very nice posting. I tend to believe that the main reason is nostalgia. But what you say is definitely true. With modern platforms you can’t get “total control” as with vintage systems. This is even true with modern microcontrollers. Modern MCUs are usually programmed in C, not in assembler anymore. And even when you do can program in assembler if you want, you usually can’t do cycle counting because of issues such as prefetch, cache, pipe-line, etc.

The difference of the main clock in NTSC vs. PAL affects everything, including the serial rate. However the difference is so small that is no significant for normal use. Remember this is an async serial interface. The receiver, within some limitations, adapts its rate to the rate of the sender. And as a matter of fact the peripherals use a slightly different rate without any problem. But it is significant for extreme cases. Some of the newer 1050 enhancements use ultra high speed that is compatilbe with PAL computers only. The OS is different in the 800/400. The XL OS is the same, and it reads the GTIA PAL registers to adapt some timings at "run-time", but not for this purpose. The OS doesn't actually care about the tiny difference of the main clock. It only cares about the difference of the frame rate 50/60 Hz. IIRC three timings are changed, attract, key repeat and tape.

It is a very good question, that probably we can only guess the answer. One possible explanation is yours, actually it could be even worse. If GTIA would use bit 0 of the luminance registers, this might break compatibility with older software. It is possible that same old games "poked" different values to that bit for some reason, while the intention was to get the same color. That could be intentional or not. The point is that if GTIA would use that bit, then the display won't be the intended one. A more likely explanation is a limitation of chip resources. Adding the extra flip-flops (for the unused bits), plus all the necessary support to make them work needs extra chip resources. Might be there wasn't enough. Again, this might be nice for enhancing the picture, but it won't be very helpful for the purpose of displaying 256 colors at once. No matter what you do. With any gr. mode besides 9, or with player-missiles, you only get 128 colors. The extra 128 colors must be displayed with gr.9. This means that short of using cycle counting (for chaging the HUE register in the middle of a scan line), you still must use 16 bands of gr.9

Changing Antic alone (without changing GTIA as well), has the problem that it will break software that was actually designed as dual-mode. The "PAL" flag is a GTIA register. So software that adapts itself to the current machine being 50 or 60 Hz, will actually use the wrong setting. The XL os itself is such a case. Some timings are changed depending on the GTIA PAL register. Notably, this will introduce problems with the tape interface.

I beg to differ about mixing graphics 9 and 11 not being very useful,... My point is, it's more useful to me as an artist, then even the DLI's are that I also use quite often with paint programs like Rambrandt. mix of 9/11 is VERY, VERY, VERY USEFUL!!! :!: 878128[/snapback] Sorry. What I meant is that mixing gr. 9 and 11 is not very useful for the specific purpose of displaying 256 colors. Of course it can be useful for many other things. The only practical way to display 256 colors is to have 16 or more bands of graphics 9, each of them with a different HUE set by a DLI. It is probably feasible to use cycle counting and change the HUE color in the middle of a scan line. That would work instead of DLIs. But it still must be done with gr.9. Using flicker or artifacts to get "visually" more colors is a completely different thing. We are talking about displaying the whole GTIA 256 colors palette. Yes, but bit 0 of these registers is ignored. More than likely this “bit” doesn’t exist in the hardware. Again, this way of phrasing is a bit misleading. The difference is not exactly between GTIA modes and CTIA modes. What makes possible the 256 colors on gr.9 (and again, only in gr.9) is the fact that the “luminance” registers are not used.

Graphics 9 is the only mode that can realize the 256 colors palette. In all other graphics modes (and player-missile) the luminance is selected using the lower nibble COLOR GTIA registers which is 3-bits only. Graphics 9 is unique in that the luminance is provided by Antic from the screen data. You don't need to mix 9/11 modes to get 256 colors, nor it will be very useful. You use DLI's with multiple gr. 9 scan zones.

Er, just for the record - I didn't say what was quoted above. :-) Oopss. Sorry, wrong quote editing.

Not IOCB. Again, IOCB is a CIO structure. SIO uses the "DCB" structure at $300. See the "Operating System's User Manual" in the Technical Notes for details. Or numerous other references. But a quick info: $300: Device Id $301: Unit number $302: Command $303: Frame direction on Input. Status on Output $304/5: Buffer address $306: Timeout in seconds. $307: Unused $308/9: Frame length $30A/B: Auxiliary bytes I think everything if self-explanatory except: $303 on input specifies if it's a read ($40), write ($80), or no data frame $(00). The actual device id transmitted over the SIO bus is constructed by adding both values in $300 and $301 and substracting 1. Unlike CIO, you don't have to setup any CPU registers before calling SIO (there is only one DCB). Status result is both in $303 and the Y register.

I doubt they really had one. Mastertronics specialized in low cost (not necessarily bad or poor), low retail price, software. I've seen ST Mastertronics originals with the source code in the back side of the disk (not complete, because the front side was overwritten with the game). This likely means: 1) The developer had no hard disk, he used floppies. Obvious signs of a young (low cost) programmer. 2) Nobody at Mastertronics checked the disk content before sending it to duplication.

Just use SIO ($E459), it's very simple. Or I misunderstand your question? You can't use XIO and IOCB, they are CIO level stuff.

Well, they are probably the minority. But there are some people that still use ST for non-gaming applications, and not just MIDI. And yes, once in a while I still hear somebody uses it's 8-bit for applications too! Don't ask me exactly why. I'm not one of those. I even use mostly Steem for ST developing instead of a real computer, and PC cross tools for 8-bit development. But even when it is hard for most of us to understand, this doesn't mean that vintage computers can't be used for applications.

Doesn't Gemulator Explorer import/export files from ATR images?

Please do it. Note that there is a big difference between "Field Service" schematics, and internal confidential ones. Field service schematics are usually board level schematics, used for repairs. Confidential docs should also include any other information needed for reconstructing/cloning/emulating the device. For example, internal schematics of an ASIC chip. Of course, if the device is made with standard TTL chips only, then a board level schematics is more than enough. But please post what you have in anycase. Many of us would love to see it.

Thanks for the information, Curt. But I guess you are talking about Mike Hohman from FTE. And I was actually asking about Mike Gustafson, who (I deduce from all what has been posted here) was the actual designer of most ICD products. So you seem to assume that Mike Hohman received all the technical insider/confidentail ICD documentation? I recall reading that the person that bought the ICD ST line didn't get any schematics or stuff like that from ICD. Is that the same Mike Hohman, or the ST line was bought by somebody else?

I have a couple of questions for Bryan (or just for anybody knowing the answer). What happened with Mike, what is he doing today? From your description it seems he was the technical brain behind ICD. Who has, where are, or were they just lost, the internal technical docs of ICD products? Like internal MIO schematics, SpartaDos sources, etc.