On 01/05/02 at 16:24 Dave wrote: >>> Essentially, when you swap QL ROMs, the video output for "TV" mode >>> changes from NTSC to PAL and vice-versa for JSU & JS, respectively.
>> Errm...don't the ROMs contain the CPU instructions...the video output is >> shurely the job of other board chips (ZX8301, etc). >> However, (these are speculation/vague memories [of rumours?]) the screen >> shape is different(?) and so the drawing routines would be modified (so a >> CIRCLE is still a circle). Also, would the interrupt routine be running >> at 60Hz as opposed to 50Hz, and so some timing routines would have been >> rewritten? Timing I think is the same, but aspect ratio is corrected. > I suspect you're both right and both wrong. A US QL with US timings would > have problems drawing a UK-resolution screen in the reduced time - I > imagine the machine would slow down greatly. Similarly, I suspect a UK QL > with US ROMs would speed up slightly. (Slower scan rate AND less to scan) No, there would be no discernible difference as the video hardware slows down the CPU regardless (I think it even does so when it's drawing th e'blank' parts of the screen that are not part of the actual usable screen area). The EU and US specs are actually remarkably similar, and only really differ in the number of lines drawn on the screen. 312 EU, 262 US. However, both are drawn on a screen that has a 4:3 aspect ratio, so EU resolution displayed on US TV would be 'squashed' vertically. IIRC the relevant routines (CIRCLE, ELLIPSE) are adjusted in the SU versions. Also, EU TV mode occupies 480 x 240 pixels, US should be 480 x 200 or thereabouts (otherwise a bit on the top and bottom would be 'off screen'). EU ROM in US QL might result in the picture becoming unstable on TVs and composite monitors when monitor mode is selected because pixels would appear in parts of the screen that should be blank and have cynch signals generated at that point. To summarise: nothing to spectacular would happen if the ROMs were exchanged. > Nasta may want to jump in, but I am also wondering what kind of headroom > the original QL mobos have for 'overclocking', in the sense of maybe adding > a faster clocked 68008FN at 10-12MHz. I think the on-board RAM would > definitely fail at those speds and may have to be removed/neutered ;) Actually, it's the 8301 that limits things. The system will stop working due to read data from the on-board RAM not appearing at the correct time over about 9MHz IIRC - I used to run my QL faster using a separate oscillator for the 68008. I had a socketed crystal but my choice of crystals was quite limited at the time, so I know that it still worked at PAL * 2, 8.866MHz. I don't remember if microdrives still worked because I had removed them at that time already. I know net dod not work because parts of the timing are software generated. It may be possible to use a bit of external logic to slow the 68008 down on certain cycles and make it compatible again. I know Stuart H had to solve that for the GC. In fact, running the 68008 at double rate would probably make the logic simpler, I suspect the 8301 generates it's cycles synchronously to the CPU clock, based on the way the 68008 generates it's signals. In retrospect, it was a wonder that an asynchronous clock for the 68008 worked at all... That being said: a board with a 68008 and some trivial logic to get the correct addresses on an Aurora, would quite efficiently work as a QL with 256k or RAM - pretty much for any speed 68008. A 68008FN and extra RAM, plus adjustment to apparent extended res screen address, would also give the user all of the Aurora extended graphics capability. I have also constructed (ah, the good old days!) a 68020 add-on board. The 68020 is quite nice because it has an 8-bit bus mode. However, the timing is different from 68008 (faster even at the same clock). I did a lot of guesswork when doing that circuit and more logic would have been needed to get it to work right. I wish I had the ability to do GALs at the time, it would have made it all much simpler - as it was, I used a few 74xxx chips, but that wasn't enough, so I could not get it to work right. The OS would come up (at that point I had my own RAM expansion which shadowed the internal 128k to make things faster so it did not rely on data returned from the on-board RAM by the 8301) but the picture was garbled and communication with the 8302 didn't work (no wonder since it's decoded by the 8301) so there was no reaction to F1/F2. I whipped this up on a small piece of protoboard during the week-end so it was no great loss when I scrapped it. The whole thing was inspired by a piggyback board that was used in the Thor20 and 21 to add a 68020 to a QL motherboard (the Thor 21 had a 68881 FPU added too). I would probably make short work of it today since now I have a logic analyzer and it would be very easy to see what the 8301 actually does - if I had a standard QL handy. One interesting thing which I found out was that a 68020 used less current at 16MHz than a 68008 at 7.5! I also know that Branko B. had overclocked the whole thing - changed the on-board slow RAM to fast 70ns, and clocked the 8301 and consequently the 68008 at a much higher rate by replacing the 15MHz crystal with a higher frequency one. This increases the video synch frequency, he used what was basically an EGA monitor. Worked just fine, too. Nasta
