Re: [Ql-Users] QL USB Interface
On Thu, 29 Oct 2009 09:59:55 +0100, Adrian D. Ives adrian.i...@ntlworld.com wrote: Tony, I'm able to do the hardware side, but my area is really in the software. If you were able to knock up some kind of interface between the superHermes (which I have) and the USBWiz I'm prepared to put in the time to look at the software. TF The only obvious silly aspect of the hardware design is that there is TF serial but no RS232 voltages. TF It needs a Maxim style chip. The reason why they do serial at TTL levels is that in general MAX232 style drivers don't do well over 230400. Surprisingly waveforms look just fine at 230400, suggesting 4-5x higher speeds are possible, but it won't do even twice that. First hand knowledge since I am dealing with a 1 or 2 megabit seril link here on a daily basis... Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] QL USB Interface
On Thu, 29 Oct 2009 15:46:34 +0100, Tony Firshman t...@firshman.co.uk wrote: Hallo Nasta - nice to see you are reading this (8-)# I am, when i can - not only does time not permit it often, but my provider tends to lose a lot of messages, either receiving or transmitting :( Thanks for the input. Well sH is max (sorry for the pun) 230400 (I think) so the max style driver is just fine. I will use my existing stock of the sH MC145407. Tony MC145407 seems to do better. Also, what Malcolm said - things like this are not intended to be connected with long cables so that RS232C levels are needed. Over short distances TTL (actually HCMOS) will do fine just keep in mind the driver chips perform signal inversion. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Unknown expansion board
On Wed, 10 Oct 2007 18:53:50 +0200, Francois Lanciault [EMAIL PROTECTED] wrote: This board is unknown to me; for what I can see in the picture anyway. What does it do ? Looks like a SuperQBoard without the RAM controller and RAM chips... ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Memory contention (CPU / ULA)
On Tue, 21 Aug 2007 19:39:50 +0200, Palenicek Jan [EMAIL PROTECTED] wrote: Hi Nasta, Thanks for great info. Thanks, thinking more about it, I should still address my time critical routines into this slow-ULA memory rather than to expanded memory, because slow memory is equally slow on all QLs, is it? Not if there is a GC or SGC. Then the memory is only slowed down when writing to it, because the GC/SGC actually maps a 'shadow' memory area to the same place. The way it works is that when data is written to those addresses, it is written both to the RAM driven by the ULA and the appropriate area of GC/SGC RAM. The slowest one dictates the speed, so that's the ULA. When data is read, it is only read from the fast GC/SGC RAM at the same address. This way code is executed (very) much faster from those addresses, but the ULA also gets a copy of all the data taht needs to be displayed on the screen. logic must have been a really tight squeeze because it would have been very easy to add a screen 2 and 3... And that would be really great to have more than two screens, no blinking Flash bit...etc. It is actually possible to add screen 2/3 switching with external logic. The ULA has two memory CAS signals, one for each bank of 64k. It also has a signal that is activated when the ULA is doing screen refresh. Screen refresh is always done in the bank selected by the CAS0 signal, if external logic activates the CAS1 signal instead, the ULA will address the top 64k of the built-in memory to do screen refreshes. Ok, I have discovered interesting ULA behavior. I cannot change screen mode earlier than on the ~5th line of the screen. ULA simply ignores status of the port. Do you know why? I have never seen this, it is possible that the fram interrupt routine forces data into the control port, so your data gets overwritten. N. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Karsten Engstler ist außer Haus.
On Tue, 21 Aug 2007 15:03:23 +0200, MB [EMAIL PROTECTED] wrote: Donaudampfschiffahrtsgesellschaft I challenge you to translate that into less than 5 English words :) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Status
Sorry to use the list in this way but it seems some people have sent me amil and it got filtered as spam by my ISP. Romaldo Parodi asked what happened with my web site - it has gone down with the spodmail ISP (don't know what happened to them exactly). I still ahve a copy and will look into putting it back on-line at some other host. Someone has also asked me about schematics and other data for the Qubide. This is still available in the file section of the Qlhardware yahoo group at http://groups.yahoo.com/group/QLhardware/ Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Memory contention (CPU / ULA)
On Tue, 14 Aug 2007 09:35:43 +0200, Palenicek Jan [EMAIL PROTECTED] wrote: Thanks Marcel! I'm no hardware guy, but I'm pretty sure the ULA locks ALL internal memory during screen refresh, i.e. depending on model (EU/US) 50 or 60 times per second. The CPU cannot access anything at all during these times. OK, I will measure read/write time in the vram anyway. ULA should somehow share bus with CPU, it should not lock memory the whole TV frame refresh. The actual sharing is quite complex and effectively slows down the CPU access buy some 40% or so, unless there is shadowing involved, like with the GC and SGC. The ULA actually requests the bus only during the active display portion of the whole screen raster generated. The total raster generated is 640x312 of which 512x256 is used, so the ULA requests the bus about 66% of each frame (one frame takes 20ms). During this time the ULA reads screen RAm bytes in bursts of 4 bytes each, to it's internal buffer. It uses page mode DRAM access to do so, otherwise it would take approximately twice the time. Depending on the synch between the CU bus cycles and the ULA timing, at best the CPU can get 50% of available memory bandwidth, and usually less. When all is said and done, you come out with about 50-60% bandwidth long term. It shoul dbe mnoted that this is true for the whole 128k of internal RAM, even though the screen memory cannod reside in the second 64k - the ULA logic must have been a really tight squeeze because it would have been very easy to add a screen 2 and 3... Some memory expansions like the Trump Card are not as limited, you do not get any delays accessing the extended RAM there. Most RAM expansions (the notable exception being some schemes which used internal piggy-back RAM expansion also driven by the ULA) are considerably faster. Expanderam/TrumpCard are not as fast as they could be but a great deal faster than the ULA addressed RAM. SuperQboard was known as the fastest, running at the full speed of the CPU. Best, N ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Size for QXL.win Files
On 08/07/05 at 11:23 P Witte wrote: John Gilpin writes: 4Gb per QXL.win file... I only get 2GB with QPC2: FORMAT win8_4000 fails while win8_2000 doesnt. Even then the file allocation block is a massive 32k. It seems to me that 4GB must be the theoretical limit for the current mapping scheme. The minimum space taken by a file on disk would then be a whopping 64k Per Per is right, IIRC QLWA may have a 2G limit, even though 4G would be the theoretical maximum. There are two possible reasons for it: 1) Maximum number of allocation blocks (think of them as a sort of super-sector) is a 16 bit word, unfortunately, some implementations and versions took it a s a signed integer instead of unsigned. 2) Maximum size of one allocation block is a 16 bit word, again some implementations and versions used signed arithmetic to point to a byte within the block, which reduces it's maximum size to 32k. IIRC the first error is the more likely to crop up. When QUBIDE was being maintained, these cropped up, but I do not remember the speciffics any more. 4G is a sort of double limit as the system implies that the whole QLWA partition can be used up by a single file. Since the file pointer is a 32 bit unsigned (hopefully!) integer, the maximum size of a file is 4G, and so is the size of the partition (64k blocks each 64k in size = 4G). The serious limitiation here is that one file always takes up at least 1 allocation block (even if the file is empty!) and the less serious one is that there can be max 64k files. The first is quite restrictive in QL terms as files are, in general, much shorter than 64k. This produces a lot of wasted space. If you want to be absolutely sure, 1G QXL.WIN, with 32k allocation block size is the way to go, it avoids all the possible pitfalls... Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Palm-top 'QL' design progress...
Since I accidentally leaked that I would be designing such a thing a few months ago, I suppose it's fair to say something about the progress of the project. So far, processors (68SZ328), Flash and RAM have been secured, I'm waiting for some Philips USB chips too. Working specs are: * 68SZ328 Dragonball derivative CPU at 66MHz * 40 or 64M SDRAM (probably 64) * 16M Flash ROM (OS boots from there) * Aurora-style 256 color graphics via VGA connector or TFT LCD (Still looking for a cheap source of these, only have 2 for testing at the moment), with touch panel support. 16 bit color is possible but resolution is limited. A rather odd 680 x 510 maximum should be possible in 256 colors, if we stick to 4:3 aspect ratios. * Built in MMC/SD Flash card slot and one CompactFash slot. The later is wired so that a sort of cartridge-type expansion is possible, for instance a CF to IDE adapter is simple to do, as well as other things like a small Ethernet, USB or modem card that plugs into this slot. * 1 standard serial port plus 1 IRDA port * A/D and D/A converter for voiceband sound record/playback (there may be a small speaker and microphone on board as well) * 8x8 matrix keyboard support (like on the original QL) * QL compatible expansion port (see notes below) * misc. features available in the 68SZ328 like real time clock, alarm, power down, etc... * very low power operation suitable for battery powered applications To be determined: * either USB-to-go (that can act as both USB device and host) on board or second CF slot where an USB adapter can be plugged in * PS2 keyboard/mouse support * Extra space for a NAND flash chip (128 Mbyte or 256 Mbyte) Size goal: approx. the size of an Aurora board, will depend on the availability of LCD displays as the idea is to mount a LCD display and computer board together. Notes: This is intended as a development platform, and the finished products will diverge into QL market ones and ones for different other markets. As such, they may not have the same complement of IO capabilities or connectors. Non-QL versions will not have the QL expansion port, for instance. In any case, this is a stand-alone machine and the QL expansion port is intended mainly for initial developement since the machine does not have a floppy controller and cannot directly use for instance a Qubide driver (needs slight modification) or have a romDisq connected to it. the port will implement a superset of the QL's address map alowing even old peripherals (but NOT QEPIII unless it is modified!, or RAM boards which I doubt anyone will need with the 40 or 64 meg already provided) to be used. 8x8 (and possibly more) keys are supported, this is a design requirement for the persons who are sponsoring this. PS2 keyboard/mouse support will depend on the ability to use the 68SZ328's SPI port for this purpose - in theory, it should work. Also, in theory there is no difference between theory and practise, so... ;-) 256 color display is natively supported on this hardware. It also provides 16 bit color support for reduced resolutions. 16 and 4 color support is possible for monochrome LCDs but 4 color is not compatible with the QL representation. Therefore, old mode 4 and 8 is emulated. The Flash ROM footprint on the board is capable of using anything from 2 megs up to 32 megs, depending on the availability of the chips. For now, we have 16M chips already in stock, and are looking into getting the full 32M. A very limited number will initially be available for developers willing to port SMSQ/E (or for that matter any OS), modify crucial driver code or write the few crytical applications... Comments and ideas welcome... Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Nasta's new email ?
On 5.1.2005 at 18:31 Brane2 wrote: Hi to all. I have tried to contact Nasta (Zeljko Nastasic) through email, but it seems that his email on QL related pages is invalid. His site works, but all data is pretty stale (1999 and older date) and his email account doesn't exist anymore. Does anyone here have his new email and care to share it ? TIA, Branko brankob at avtomatika dot com Sure: here it is - zeljkoDOTnastasicATzgDOThtnetDOThr Nasta ;-) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Holiday Music For All !!
On 24.12.2004 at 22:23 Paul Holmgren wrote: http://www.inet.hr/~sazivano/Move/Farting_Santas.htm And on a Croatian site, no less - someone has too much time on their hands in this country ;-) Season's greetings, everyone, and all the best in the new year! Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Trump Cards and FORMAT
On 10/12/04 at 12:24 [EMAIL PROTECTED] wrote: 1. Qubide II - definitely. Whether QL expansion is SGC or whatever, Qubide remains the only option for hard disk expansion via IDE from a QL or Aurora systems. This is doable, but requires a minor and/or major upgrade to the driver. The minor part is centered about keeping the driver and the disk format the same, just catering for minor differences in the hardware (line not needing to set any jumpers at all and the capability to work with romDisq). Possibly, the initialization sequence could be simplified. All of this assumes that the Qubide source (latest version) is available, and AFAIK, it is (Roy? What is the legal status of it?), and also assumes a person that can look into said source, understand the necessary bits, and change as needed. It may be prudent to start a repository of sources, perhaps best at the official SMSQ site? The major part is more radical. It is high time that hard drive partitions and formats be unified on QL platforms, and in fact, it is only Qubide that does not directly conform to the norm. It should be possible (indeed, it should not be much work) to convert the SMSQ/E win drivers for Qx0 to run on Qubide hardware. The problem here is the lack of utilities. Qubide's format and partition utilities are, to my knowledge, far more than is available to the Qx0 user. Still more radical, it should be possible to support both types of partitions as well, but that requires a lot of work on the driver(s). There are also issues associated with both drivers, namely use of slave blocks and keeping the disk map (FAT or derivatives) in memory... 2. Ethernet - no use for it myself, but people have said on this list they want it. The hardware here is almost trivial, but the software isn't, unless one limits oneself to a modified NET driver that can run on Ethernet hardware. One gets a quick QL network but nothing else... OTOH supporting TCP/IP could in due time expand the usefulness of such hardware imensely. 3. SGC-type expansion. Something is needed, whether you go down the traditionalist path for a plug in and go Miracle-style expansion, or a much more radical path... You have to decide if you wish to go the expansion route (i.e. plug into QL or Aurora) or go for some completely new hardware such as the one you said you are developing for your employer. Actually, it is likely that both will be made available. The 'low end' system would be ehat my employer wants: Very close to a fully kitted out black box QL and then some, as we can make it now. The difference is, that everything is integrated and it is very small - about the size of an Aurora. Functionality is not a quantum leap over that, but it is higher than what we already have - most notably RAM is increased to 32 or 64M, on-board 16M (with support for future 32M chip incuded) Flash for program and data storage is provided, up to 50% more speed than SGC (so still a far cry from Q40), built-in graphics that is similar in some respects and improved in others compared to the Aurora (eg, you can't have more than 512 pixels vertical but you can have 256 colors in all resolutions, and 16 bit color in some, including standard VGA 640x480). Varioous standard ports are included. New features are MMC flash cards, and USB (possibly also ethernet), sampled sound support (mono). CF card support has been seen before, the difference is that connecting a standard IDE drive involves a CF to IDE adapter is needed, not the other way around as would be traditional. It will probably also have a QL type expansion port for peripherals ONLY at least on prototypes - in order to connect a floppy interface or Qubide, to transfer data when setting up the system. It does NOT have a floppy interface - one can be added externally. The video output can also be used as an interface to a TFT LCD, including a touch-screen option. So, it's some of the old with some of the new, in a nice small package - usable as anything from an interesting toy to an industrial controller. Obviously, many features will need to be supported in the OS, either through modified existing drivers, or through completely new ones. The 'high end' is a version of GoldFire or a re-hash of that design using a top of the line ColdFire V4e CPU. In either case, the designs have radicalityt to them: GF design introduces dual processors (I have been going on about this for years now and lo and behold this is the next step the mainstream is taking, admittedly with dual core CPUs instead of dual CPUs, but the idea is similar if not equivalent), along with a full stack of new hardware features, which also involve additions to things like interrupts (by introducing dedicated interrupt levels for fast peripherals and having the ability to route them to either of the two CPUs). Lots of OS and driver work that should prove essential in the future (if there is to be one). This one has the disadvantage of using 68060, which is now officially obsolete, so
Re: Re: [ql-users] Trump Cards and FORMAT
On 10/12/04 at 10:46 Phoebus Dokos wrote: [Qubide driver changes] Possibly, the initialization sequence could be simplified. All of this assumes that the Qubide source (latest version) is available, and AFAIK, it is Yes it is :-) The latest QubIDE v.2.02 is already incorporated in QDOS Classic btw :-) Great, so we do have someone who knows how to poke around the source. In essence, the only truly important thing to do is change the IO addresses to a fixed value for GC/SGC systems. It uses a small area in the QL's IO block, which to the best of my knowledge doesn't interfere with anything. Also, the initial copying of the ROM to RAM is handled slightly differently, there is more space available and once the ROM is copied from it's initial address that switches off the ROM slot, it restores the ROM slot and whatever is in it should then be initialized as usual (the procedure is outlined in both the extended UM and the technical guide). The major part is more radical. It is high time that hard drive partitions and formats be unified on QL platforms... does not directly conform to the norm. It should be possible (indeed, it should not be much work) to convert the SMSQ/E win drivers for Qx0 to run on Qubide hardware. The problem here is the lack of utilities. Absolutely true... and when the QubIDE software is run on a Q40 or Q60 thanks to the wonderful work of Derek Stewart, many of the problems experienced with the regular QubIDE software (ie Not a QubIDE partition message appearing out of nowhere) are now gone. Same would be true for the new Qubide. Signal integrity is well taken care of. However in all truth, there is a GREAT SMSQ/e partition tools only it doesn't run under SMSQ/e... it runs under Linux (atari-fdisk) and it's worth to boot a ram-based linux only for atari-fdisk :-) Actually, if the driver was extended to support direct sector access (ah, shades of metadevices again!), porting that or even using modified Qubide tools would be possible. It strikes me as quite strange that no-one has done this yet for the Qx0... Still more radical, it should be possible to support both types of partitions as well, but that requires a lot of work on the driver(s). I am not sure if it feasible without major changes in the QubIDE software Not necessairly - internally, QubIDE partitions are stand alone just like Atari style ones - they could fairly easily be made conformant with the FAT16 style partition table, there are very few places in the Qubide driver where this is accessed (notably win_use, either explicit or implicit at initialization time). From there on, two drivers could exist, win and something else (qub?), with win_use and qub_use commands. The usual win_use parameters would apply to both, but each driver would only link in a partition if it was the required type (QLWA or QLW0 respectively). Even so, we really need to unify the format at some point... [Ethernet] The hardware here is almost trivial, but the software isn't, unless one limits oneself to a modified NET driver that can run on Ethernet hardware. For that it is most likely that Peter's work on QlwIP will be almost trivial to adapt to a new EtherIDE (AFAIK Peter's hardware driver is for the Realtek chipset which is IIRC what you were going to use too) Actually, I use the SMSC LAN91C96 which is similar but also different from the Realtek. The Realtek has turned out to be a dead end - they only have PCI versions now and they are not compatible with the ISA based one used on the Qx0. Also, this assumes that Peter would be willing to do the work, which I am not sure he would (and I hope I get to be proven wrong). SMSQ/E licencing issues are likely to rear their head again but this could be circumvented by supplying the module separately, though it should REALLY be a part of both OSs. 3. SGC-type expansion... a plug in and go Miracle-style expansion, or a much more radical path... Actually, it is likely that both will be made available. When is the keyword here :-D I'm looking at 10 68SZ328 chips right in front of me at the moment, SDRAM and Flash are scheduled to arrive in a few weeks. PCB design is still to be started once a definitive spec is drawn... The video output can also be used as an interface to a TFT LCD, Without an inverter or is it a DVI output? It's a raw digital output to connect directly to a TFT panel, and I do have a supplier for same plus inverters... in the USA... but I haven't as yet been able to find a nice small 640x480 color TFT with touch screen... As such, this digital output can be used to connect a DVI transmitter chip as well, so that option is also covered. GF design introduces dual processors (I have been going on about this for years now and lo and behold this is the next step the mainstream is taking, admittedly with dual core CPUs instead of dual CPUs... ...Lots of OS and driver work that should prove essential in the future... Stop it you make
Re: [ql-users] Trump Cards and FORMAT
On 09/12/04 at 12:35 P Witte wrote: Life should have a pause button! Nasta? And during the pause, I need to get a passable facsimily of me made to handle day to day affairs, while I concentrate on things I really like doing, like designing hardware for the QL ;-) On 09/12/04 at 08:04 Phoebus Dokos wrote: Well I would love to know as well - all I do know is that Super Gold Cards are soon snapped up as soon as people know that they are available. Even at 80 plus pounds a piece (which shows how badly a new standard expansion card is needed (Nasta?) Or at least more SGCs... Why do you think I posted the lengthy messages about ColdFire vs 68k? At this point designing a new standard card requires a rather major decision involving a problem quite similar to what was being discussed in the original thread, namely, leaving some of the past IN the past. Even the GoldFire design (even though, in it's last iteration, it did not have much to do with ColdFire CPUs) was intended to run QMSQ/E exclusively, or at least as the first option. Of course, no one would be stopped from porting QDOS classic on it or indeed anything they saw fit - which is why the documentation was freely available. It can still be made with the original pair of 68060s (one required, one optional). The performance would be slightly faster than Q60 as it utilizes faster RAM, and this is certainly quite powerful in QL terms. Redesigning for CF V4e would push the performance up by a factor of 4, ASSUMING the differences in architecture are suitably handled - and note that at this point, 'suitably' is signifficantly complicated by the nead to provide near 100% compatibility. All of this means that the OS developers Marcel mentioned in his astute email (in fact, I don't remember Marcel ever NOT being astute and to the point in any email), would certainly get space to develop. But even if they do and all the extra nice hardware features are supported, nothing will happen if applications actually don't use them. Now, there are two ways about this: Either I design what i think I should, even breaking compatibility in places where it's the sensible thing to do, and ignore the rants of the sticklers-to-the-old, inviting the formation of yet another rift in the shrinking community. A sort of this is the medicine, take it or leave it approach. Lots of time and money involved, and most certainly not only for me. I could get back into 68k programming with months needed to tackle the SMSQ/E sources so I can actually do rudimentary support for all the newfangled bits - which in practical terms means it probably would never see the light of day - or I can ask for help (and I have), and write good specs and documentation for developers to follow. At one pont, the can't make omlet without breaking eggs addage becomes all to apparent... Or: I attempt to get the 'feel' of what people in the community want (as oposed to what they need) and in effect this is, all told, a net zero vector - so I just pack it in regarding any even slightly radical developement, or even all developement altogether. At this moment, I could solely concentrate on a few simple things i could do - an Ethernet board, a simplified Qubide II of sorts - things that I know I can do because they require comparatively less investment (parts available, 2-layer PCBs, etc). Sales would be very limited, but so would the investment. Alas, even these assume at least GC if not SGC. So, what should I do? N. PS - in a recent mail someone said that most users that do not want to upgrade to SMSQ/E don't want it because theyt would have to use the PE. To my knowledge SMSQ/E does not come with a built in bomb that explodes if one does not use thge PE part of SMSQ/E, I just don't see what part of it would MAKE them use it? Oh, and I have no doubt that quite a lot of the same lot use Windows on a daily basis am I the only one who sees this as ironic? ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Trump Cards and FORMAT
On 8.12.2004 at 1:09 Mike MacNamara wrote: The latest CPUs need a lot of amps on the +12v lines, the AMD64s need at least 18 amps barebones just to post. but 30amps will run them OK. OK, let me sort this one out so that we can go back to QL things: Actually, that may not have anything to do with it. The motherboard components do not use 12V directly, and in some cases not at all. What this is about is the core voltage supply for the CPU. Even though this is a low 1.5 - 1.75V in most modern CPUs, the current needed is quite astounding - 50 to 60 Amps is not uncommon. In oreder to get this sort of power supply to a CPU from an external power supply, one would need wires and connectors with a cross section abut the same as those connecting a car battery to the starter - i.e. some 10mm in diameter - completely impractical. This is why the required voltage is supplied from an on-board converter. It is left to the board designer to decide wether this converter runs off the 5V line or the 12V line. Depending on that decision, running a fast CPU on a given motherboard may require the power supply to provide extra Amps on the 5V or 12V line. If your motherboard uses an ATX2 additional 12V power connector (kind of like a shorter, almost square version of the usual large ATX power connector, with only 4 wires, two black and two yellow), your power supply needs more current capacity on the 12V line. If not, then on the 5V line. It may be worth noting that the on-board converter(s) operate like true transformers - Volts out times Amps out (=power output) equals Volts in times Amps in (=power input), minus conversion loss (10-15%). What this means is that using 12V to power the converter requires less amps than using 5V. This is the reasoning behind the small extra ATX2 connector (also known as the P4 connector) - connector contacts also have current limits. Unfortunately, driving the converter off 12V also has other consequences, but this is truly well outside the scope of this message. As a rule of thumb, for the purposes of supplying power to the CPU, every 1 Amp on the 12V line counts as 2.4A on the 5V line. All of this assumes that no other components are signifficant loads on these lines - in reality, they are not large loads, but may just be what trips the current limit in the power supply. Also, AGP graphics can be a demanding load on the 3.3V line... OK, now that you know everything about choosing the PCs power supply, we can go back to QL thematics ;-) Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] ColdFire vs 68000
On 03/12/04 at 02:19 Marcel Kilgus wrote: For the fun of it I did some greps over the whole sources on my first WIN partition (mostly SMSQ/E and some stuff like QPAC2, EasyPtr etc) to have some data: dbcc: 324 exg: 474cmpm: 24rol: 168 ror: 367 roxl: 25roxr: 45 ori2ccr: 7 eori2ccr: 1andi2ccr: 5 It would be interesting to see where the EXG, ROL, ROR, ROXL, ROXL instructions occur. I would bet quite a few in the graphics driver... Long-word forms only: Most arithmetic and logical instructions can act on Long words only add: 3417 adda: 222 addi: 36addq: 1853 addx: 225 asl: 48 asr: 80 cmpa: 12 eor: 175 eori: 14lsl: 803lsr: 804 neg: 314 negx: 1 not: 270or: 847 ori: 67sub: 1685 subi: 43subq: 2504 subx: 4 These are much more difficult to sort out - the big question is, wether the actual operation must be .B or .L, in other words, the upper bits of the register need to remain unchanged. And, of course, it is one thing if an emulated instruction EXECUTES seldomly (as opposed to appears in the source code) or is executed often, and/or nesteed in loop(s). Rewriting the latter code to be CF compliant is well worth investing into, the rest can always be left to emulation. Well, but basically I see two classes of instructions: the ones that are seldom used and therefore emulation is fast enough and the ones that are so often used that it is not manageable to exchange them... Actually, it's not as simple as that. There are 4 basic cases: Emulated/replaced * source_available/source_not_available. For the cases where source is available, one can opt for automated cross-assembly, using for instance MicroAPLs portASM68k. This is a tool that ypu can download for free after you fill in a web registration form at freescale.com. It is worth noting that MicroAPL offers other portASM products, and indeed CPU emulators (called MIMIC) as well as cross-compilers that can take 68k asm source and cross-compile them into C. Freescale/Motorola is obviously very keen on getting CF to occupy a larger share of the embedded market as these MicroAPL products are normally VERY expensive. For instance, MIMIC that emulates 68k on PowerPC chips costs $5500 as a developement system and over $1000 as a deployment licence. Anyone attempting to write an emulator, or indeed, that has written or is using an emulator, should look at these figures... Even though PortASM68k is free, it is quite well documented and it is probably well worth unleashing on selected parts of SMSQ/E source and then looking carefully at the output and log files. It is actually a rather clever program, however, someone deeply involved in the source could probably do a better and far more optimal modification by hand. The big question as always is the tradeoff between suboptimal code that takes a fairly short time to produce using an automated translator, or optimal code that takes a longer time to produce by hand. IMHO optimisations are sure to follow once an automated translation starts working - and some (possibly considerable) hand optimizing will take place. The crux of the matter is, does it actually take any longer to get the finished product (as opposed to working product) if optimizing by hand was done from the start for the most critical sections of code, without the automation ever being used? The real test of how well such translation performs would be passing the sources for SMSQ through it, assembling them, and running them on the same machine (the differences re USP/SSP and associated stack behaviour should be left alone, portASM provides for this), then comparing code size and performance. At some point, whoever is doing either the cross-assembly or the manual changes might decide, on a case to case basis, not to bother with certain code fragments, and assume there is an emulator present. For the cases where the source is not available, emulation is the only recourse, but no doubt cases will crop up where emulation fails. Work will have to be done to find the cause and patch the offending code by hand. One would expect that these will be relatively rare occurences, but it is also plausible to expect these cases to be tough nuts to crack. What it comes down to is this: 1) How good is PortASM at what it does? 2) How good is the emulation library and what instruction set should be emulated? The first needs to be tried and evaluated. The second is a different case and for it, I propose something like an address extended 68000 but with limited FPU support. I have just looked at V4e user's manual and it appears that the FPU is in fact semi-compatible to the 68060 implementation, however it only does double precision. IIRC this can be converted to
Re: [ql-users] The hardware
On 30.11.2004 at 18:21 Marcel Kilgus wrote: The SGC can actually access the Aurora ROM chip proper... what is unclear is if it can also generate write cycles on the bus for those addresses. Can't one see that in the chip code Keith has recovered? YES! So didn't you get them? I had a brief look at them ages ago and had the understanding that they're on their way to you. No, never got them... I only saw them when Keith oiginally got them and they were really faxed through and quite unreadable at that point. I have no idea what happened to them after that. 1) CPU a) 68k (semi)compatible or an alternative - the latter requiring a complete re-write of nearly everything or at least a very capable emulator. I don't see much use in an alternative CPU. In that case better get a cheap PC and get some emulator whose name just slipped my mind. That would be the most logical choice for a regulat 'home use' machine, but not at all for something which can also be sold on the embedded market. SMSQ/E could be interesting in such markets even if emulated, but not at the price of involving PC hardware (although price is OK, reliability is questionable as is the cumbersome nature of it). b) 68060 or Coldfire - 68060 being the obvious compatible choice but suffers from obsolescence... Coldfire has the semicompatibility problem. You probably just have to wait another few months and they'll get completely compatible again ;-) Actually, Motorola/Freescale just announced data for their V5 core. They did put back a few more things but most of the semi-compatibility remains. Even so, if you had the time to look at that long email on this issue, it's a whole lot more manageable if you restrict things to emulaing 68000 plus a few choice extensions. 2) Format a) PC influenced or industial - in other words, uATX (flexATX or ITX) or Euro/halfVME. Just my feeling, but I'd opt for small and something like a Euro card. Yes, I like small put fun toys too ;-) The ATX/BAT market is already served by the Qx0. Actually only BAT and that is very much dead. I'm thinking of even smaller. b) Fully integrated or expandable... integrated with minimal expansion but also fairly costly solution Does it make that much difference price wise? For the finished product, no - the PCB is a fairly minor investment, 30% or so savings on it will not make it much cheaper. On the finished product you just don't populate the board with the bits you don't need. The developement is where you have to put lots more money - you cannot really split the project into segments and have actual hardware released one segment at a time. In the long run the costs are quite likely the same, but short term, the integrated approach requires much more $ at once to develop and set-up manufacturing. flexATX is that part of a regulap PC ATX motherboard that has the serial, parallel, USB, keyboard, mouse and sound connectors Roughly 23 x 19cm, I gather. No, actually smaller. Think ATX with all the slots taken off. In fact, if you take an ATX motherboard and look at it so that the IO connectors are along the top righthand edge, and the PCI etc. slots on the lefthand side, you will see it has 6 main fixing holes. Take the 4 rightmost - 2 near the IO connectors and 2 usually just in front of the RAM sockets - they ruyghly delimit the size of a FlexATX board. So, it's about 17 x 18cm. N. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] The hardware conflict...
On 30.11.2004 at 11:25 Dave P wrote: I know a bit about the romdisq and it sounds like an interesting piece of hardware. How does the romdisq compare to a cut-down qubide with space for one or many CF cards? Not that there's much to 'cut down' on the already very sparse qubide! If a dedicated CF-only Qubide was made, it would be signifficantly sparser, indeed - if it went onto the expansion bus or onto the ROM slot of an Aurora (that one has the requisite 'write' signal unlike the standard port), it would need one CF connector, one GAL and some means to hold the boot code, perhaps a small Flash. The nice thing about romDisq is that having a true ROM mode means you can actually get the driver for romDisq onto romDisq itself and still have the QL see it and initialize it correctly at start-up. Not at all easy (verging on impossible) with CF so you need another form of ROM to hold the driver. Also, on a dedicated CF adaptor, one more chip would have to be used if the CF card itself is to be hot-swapable, however it is doubtfull this would be needed as the hardware itself would only be slightly larger than the CF connector, and therefore only very slightly larger than ROMdisq. With an approach like romDisq, the hardware would stay very similar to romDisq - one programmable logic chip, one ROM-like device for the driver, and a CF connector. N. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Aurora screen resolution
On 30/11/04 at 04:02 James Hunkins wrote: LCD panels have a 'native' resolution where every pixel is physically represented by an element within the panel. Lower resolutions are 'scaled' down either by the graphics drivers or by hardware (panel or graphic driver chip). Lower resolutions will never be as 'clear' and the native. With only one exception: when they are exact whole number multiples of the native resolution. This is actually quite difficult to do as there are no lower resolutions used in the PC world that would scale properly into 1024x768 (most common resolution for 14 and 15 LCDs), unless of course you own a QL (512 x 384 - but NOT 512x256, see below). For 17 and 19 LCDs, the most common native resolution is 1280 x 1024. This is actually even worse because it's aspect ratio is 5:4, not the standard 4:3 or wide screen 16:9. On such a screen not a single Aurora resolution will look it's best. CRTs are better as they are very scalable up to their max resolution. But I personally will never go back to them as the better panels today are just so awesomely brilliant and sharp (now that you no longer have to allign a moving electron gun, along with scattering/bleeding issues, etc that are inherent to CRTs). I will do the same just as soon as I can get a 2048 x 1536 LCD for $300 or thereabouts ;-) But that being said I do own a 17 wide screen, 1280x768 LCD ;-) unlike CRTs some (at least some, if not most) LCD panels have a preferred resolution and have difficulty with anything else. This is actually a shamefull show of corner cutting. Because of my job I had to look at the specs for many LCD monitors and bare panels, and EVERY SINGLE ONE uses a scaler chip that can scale any resolution (including ones far odd-er than provided by Aurora!) up to some maximum (usually 1280x1024) to the standard LCD panel resolutions. It's just that manufacturers do not bother with providing the simplest math to program the scaler properly - and I might add, math for which they alrady have all the data about the resolutions, frequencies etc provided by the signal source, and which is far more difficult to measure. Some of the programming I've seen in this area is just horribly incompetent - more proof that PC style programming (memory leak = go buy more RAM and learn to write propper code) is killing the art... N. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] The hardware conflict...
performance at the expense of low code density... This all means that programs compiled for RISC processors tend to be substantially larger than those compiled for CISC architectures such as the 680x0. This penalty does not greatly matter for powerful servers or workstations with 64MB or more of RAM, but for some embedded applications it can be a significant disadvantage, both in terms of system cost and power consumption. The ColdFire architecture... is optimized for code written in C or C++, and instructions which are not frequently generated by compilers are amongst those removed from the instruction set... In order to regularize the instruction stream, ALL COLDFIRE INSTRUCTIONS ARE EITHER 2, 4 OR 6 BYTES WIDE, this is why certain combinations of source and destination operands are not available. Missing addressing modes: The ColdFire addressing modes are quite similar to those of the original 68000, i.e. without the extensions introduced in the 68020 and later processors, but with some differences in indexed addressing. Compared with a 68020 or later processor, the comparison is as follows: Fully supported: Data Register DirectD0 Address Register Direct A3 Address Register Indirect (A5) Post-increment (A1)+ Pre-decrement -(A7) Displacement (16-bit displacement) 100(A2) PC Displacement (16-bit displacement) 100(PC) Absolute Short ($100).W Absolute Long ($220E0).L Immediate #3 Partially supported: Indexed (10,A2,D3.L*4) PC Indexed (0,PC,D2.L*2) The restrictions on these two modes are: (a) The displacement constant is 8-bit only (b) 'Zero-suppressed' registers are not supported (c) The Index register can only be handled as a Long. Word-length index registers are not supported. (d) The scale factor must be 1, 2, or 4. Scale factors of 8 are not supported. Not implemented at all: Memory-indirect post-indexed([12,A3],D2*W,1000) Memory-indirect pre-indexed ([12,A3,D2*W],1000) PC-indirect post-indexed([12,PC],D2*W,1000) PC-indirect pre-indexed ([12,PC,D2*W],1000) NOTE THAT FURTHER RESTRICTIONS MAY BE IMPOSED ON THE ADDRESSING MODES SUPPORTED BY PARTICULAR INSTRUCTIONS, EVEN IF A PARTICULAR ADDRESSING MODE IS ITSELF AVAILABLE ON COLDFIRE. Missing instructions: A number of instructions are not implemented at all under ColdFire. These include: DBcc, EXG, RTR, RTD, CMPM, ROL, ROR, ROXL, ROXR, MOVE16, ABCD, SBCD, NBCD, BFCHG, BFCLR, BFEXTS, BFEXTU, BFFFO, BFINS, BFSET, BFTST, CALLM, RTM, PACK, UNPK CHK, CHK2, CMP2, CAS, CAS2, TAS (supported in V4 core), BKPT, BGND, LPSTOP, TBLU, TBLS, TBLUN, TBLSN, TRAPV, TRAPcc, MOVEP, MOVES, RESET, ORI to CCR, EORI to CCR, ANDI to CCR In addition, DIVS and DIVU (with some differences from the 680x0 equivalents) are available on some ColdFire processors but not others. MULU and MULS producing a 64-bit result are not implemented, but 16 x 16 producing 32-bit, and 32 x 32 producing (truncated) 32-bit, are available. [Comment by ZN: Out of the above, DBcc, ORI EORI ANDI to CCR are obvious problems, and ROL ROR ROXL ROXR although seldom used do appear in QL code. Most of the others are no great loss... although some bit field instructions would have been nice...] Long-word forms only: Most arithmetic and logical instructions can act on Long words only. This applies to: ADD, ADDA, ADDI, ADDQ, ADDX, AND, ANDI, ASL, ASR, CMP*, CMPA, CMPI*, EOR, EORI, LSL, LSR, NEG, NEGX, NOT, OR, ORI, SUB, SUBA, SUBI, SUBQ, SUBX *For the ColdFire Version 4 core the CMP and CMPI instructions are fully supported. [Comment by ZN: these are a serious problem as they are very often used. They can be enulated but emulation can be particulairly inefficient if one absoultely needs to calculate the V flag] MOVEM.W has also been removed from the instruction set in all versions. In fact, the only instructions which do act on the full set of byte, word and long operands are CLR, MOVE and TST, together with CMP and CMPI for the V4 core. EXT.W, EXTB.L and EXT.L survive in all versions, as do MULx.W and MULx.L Instructions which act only on registers, not on memory: Some arithmetic instructions cannot act directly on memory - the destination must be a register. This applies to: ADDI, ADDX, ANDI, CMPI, ASL, ASR, LSL, LSR, NEG, NEGX, NOT, EORI, ORI, SUBI, SUBX, Scc Note that ADDQ and SUBQ can act directly on memory. Restrictions on addressing modes for particular instructions: Even where a particular memory addressing mode does exist in ColdFire, some instructions are subject to further restrictions. Often, this is because of the limit of six bytes as the maximum length of a single instruction. Specific restrictions include: (a) Some combinations of addressing modes for MOVE are disallowed: If the source
Re: [ql-users] The hardware
OK, let's see if my email is FINALLY working right! Phoebus Dokos and Marcel Kilgus wrote: The Aurora CAN display 256 colours on 640x480 but the Super Gold Card prevents that by taking some of its addressing space. Check your facts. This is simply wrong. The memory organization in 256 colour mode is 512 bytes per line, there CAN'T be a 640x mode. There is also a special diagnostic mode that can go up to 1920 x something - I have used it ONCE so can't remember much any more - Refer to Nasta's epic emails for more details :-) This is also wrong. The diagnostic mode is 1024x960, so just a few more lines. Marcel To make things clear: The absolute maximum resolutions of the Aurora, assuming no limitations of monitors, refresh rates or address space are as follows: 4 colors (QL format): 1024 x 1024 8 colors (QL format): 512 x 1024 (I know, silly, but that's how the QL format works) 16 colors: 1024 x 512 256 colors: 512 x 512 The only and unfortunately unavoidable reason for this is that there are only 256kB of addresses available to hold the Aurora screen memory area. Thus, 1024 x 1024 x 2 bits = 2Mbits = 256k, as is 1024 x 512 x 4 bits and 256 x 256 x 8 bits. Predictably, the Aurora uses one 2Mbit VRAM (a special dual port dynamic ram intended for frame buffers on graphics cards), organized as 156k x 8 bits, in other words, a 256kbyte RAM. Other limitations force the actual resolutions that the Aurora actually displays even though the above ones are possible in theory. One is that you can get a theoretical maximum of 2500 bytes a second out of the second port on the VRAM, in other words, this is the maximum speed at which bytes representing pixels can go out of the RAM to be drawn on a screen. Also, the maximum speed at which pixels can be generated (nothe that one pixel only equals one byte in 256 color mode) is 6000 pixels a second. These two limitations as well as the pixel arrayt organisations above and the size of the VRAM cannot be circumvented with current hardware. However there are things that can be changed, and without too much work, I might add. For one, assuming one can reduce all additional expansion save the Aurora to the ROM port, the full resolutions could be used if the EPROM marked SCAN is loaded with slightly different code. In fact, the existing code can be altered so that for standard, VGA and SVGA monitors the Aurora behaves as it does now, but the final setting, that for Multisynch monitors (in fact all available today should support this setting), has an unused option, which is Multisynch Interlaced. When this is activated via the monitor type jumpers, 1024 x 768 in 4 colors will actually display the diagnostic mode, 1024 x 960, however, this will be in interlaced, as the 6000 pixels per second limit forces this. This setting could be fairly easily replaced by a new monitor definition that would use all the available memory. Also, there is a possibility of using a Flash ROM instead of the EPROM that holds the OS. A half meg device could easily hold QDOS, Minerva and SMSQ/E. This however needs a bit more work, in particular with the (SIC!) GC/SGC ROM. Also, there are some things unclear in the way SGC decodes memory which may make it impossible to program the Flash ROM in the Aurora - it may need to be programmed on a chip programmer. Finally, there seems to be a world-wide shortage in such chips hosed in teh standard DIP 32 package, but PLCC 32 (far smaller and require an adaptor, which, fortunately, is not expensive to make) are easily and cheaply found. Finally, a small change in the logic of the large programmable chip is needed to enable the in-circuit programming of the Flash chip on the Aurora (when the Aurora was designed, such chips were still quite exotic). There is a batch of about 20 remaining Auroras for shich I am working on to include this functionality. It would be possible to modify all existing ones to include it as well. That would about stretch the capabilities of the Aurora as far as they could possibly go. One other improvement could be possible assuming a replacement is made for the INGOT20 programmable chip on the SGC - it would speed up data transfer between the SGC and Aurora (and indeed other expansion cards that could use it) by a factor of at least 2. Unfortunately, very little if any SGC documentation remains. Such a replacement would entail desoldering the INGOT20 socket and connecting a special small adapter PCB with a different and new programmable chip. Assuming larger capacity RAM is available in a ZIP package, it would also be possible to expand the SGC RAM to 15Mb or so, using the same replacement INGOT20. Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] The hardware
On 29/11/04 at 15:56 Marcel Kilgus wrote: ZN wrote: OK, let's see if my email is FINALLY working right! Hooray :-) Ditto = finally!!! This setting could be fairly easily replaced by a new monitor definition that would use all the available memory. But which would only result in even queerer resolutions like 1024x1024? Especially with the trend clearly going to LCDs I don't think this is worth it. I only have LCDs in the house and while developing the driver it was difficult enough to test modes like 512x480... I actually have a LCD for testing purposes and will probably at some point ammend the SCAN ROM for better compatibility. Or, failing that, I will explain how it works and someone else can create the necessary contents ;-) Of course, you do have a point there. About the only useful extra resolution to have would be 1024 x 512 in 16 colors but since there is no driver, it's a moot point. There is another possibility that I have been toying with that would be VERY simple to incorporate if the MAC programmable chip is reporgrammed, which is what it needs to implement Flash ROM compatibility - and that would be re-enabling two screens even in higher resolutions and colors. The whole memory area would be enabled and could hold up to 2 x 1024x512 in 2 colors (fairly useless), 2x 512x512 (used as 512x256 or 512x384) in 16 colors (also fairly useless) but also 2 x 512 x 256 in 256 colors. Maybe we get an arcade style game for the Aurora out of it ;-) Also, there is a possibility of using a Flash ROM instead of the EPROM ...Also, there are some things unclear in the way SGC decodes memory which may make it impossible to program the Flash ROM in the Aurora - it may need to be programmed on a chip programmer. Which is not really an option, is it? It's probably okay for QDOS and Minerva, they haven't been updated for ages, but with SMSQ/E you'd be back to status quo, having to load it from a device after booting another OS. Agreed. This is why some exploration is needed... The SGC can actually access the Aurora ROM chip proper (and the SGC ROM chip as well) at alternate addresses (starting at $40 IIRC), what is unclear is if it can also generate write cycles on the bus for those addresses. Obviously, these write accesses are needed to write the new contents of the Flash ROM. If yes, adding Flash capability is a nice bonus. If not, the last 20 or so Auroras get sold as bog standard Auroras and not a 'Special Edition' ;-) One other improvement could be possible assuming a replacement is made for the INGOT20 programmable chip on the SGC - it would speed up data transfer between the SGC and Aurora (and indeed other expansion cards that could use it) by a factor of at least 2. I'd say better invest the time in a complete replacement for the SGC ;-) I would tend to agree - but some facts should be mentioned as well: 1) All of the above are fairly trivial things and therefore can be used as stop-gap measures 2) There are a number of Auroras and SGCs out there and such mods are very cheap, unlike a whole new replacement - this has to do with the required critical mass of users, mostly. Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] The hardware conflict...
*** REPLY SEPARATOR *** Dilwyn Jones wrote: I use a ROMDisq in this situation, though a new 128MB ROMDisq would solve the problem. Technically I could make a 16mb RomDisq with the existing hardware. Unfortunately the minimum chip buy is about UKP5,000, so not on. This all sounds a bit silly when you consider that a cheap compact flash card and reader for the PC costs about £12. ...CF crad readers which work with Qubide do exist In fact, the Flash chip market is swamped by huge overdemands - right now it has become even more difficult getting small amounts of chips because orders of several tens of thousands are not uncommon. In the case of flash ROM used in USB keys and CF cards etc (which are of different type but actually more suited for something like romDisq - unfortunately they were in their infancy when romDisq was designed), it is nearly impossible to get samples - the best wai is to find a cheap flash key and take it appart - and for small runs, the cheapest too. I have recently corresponded with a Samsung sales representative and they told me that I could get my parts in a year or so (a few hundred) unless i ordered several hundred thousand in which case they would bump down another large customer on the waiting list! The chips in question are 1Gbit capacity (128M bytes), the most common chip used in USB flash storage. In the end I got my sample by dissasembling a brand new USB flash, one of the older types which was large, easy to dissasemble and quite cheap too ;-) That being said, it seems that I will be getting a few samples of the new 16Mbyte (128Mbit) regular flash, which are to be used in the small porta-QL design I talked about at QL2004. These are selectable byte/word organisation devices, alas not directly usable on romDisq... Nasta ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] The hardware conflict...
On 25/11/04 at 21:07 Dave P wrote: The QL uses such minimal power that unless we are using Coldfire this can be ignored. Not so. On the typical PC laptop motherboard is a charge control circuit to regulate the current to the battery, and power monitoring to select whether the battery is charged, used, or ignored. Actually, the QL uses quite a lot of power by today's standards for low power devices, but definitely negligible compared to today's laptops. Using a Coldfire CPU (which has it's own problems I may find time to discuss in another email), things can only get better - the most power-hungry Coldfire uses only about 2W of power. To give you some perspective, it could run for approximately an hour and a half on an average mobile phone Li-ion battery. hard to disagree this point) then what is really in demand is an embedded QL-compatible platform that can be a desktop or laptop board, or used for control/monitoring functions, etc. It would need to be a board of two halves, logically speaking. A standard processing, OS, memory and required interfaces half and a custom interfaces half (if that counts as half). Ironically, this is more-or-less what Nasta designed as the Aurora II. Heh... but sometimes I really hate being right about some things ;-) As it happens, my current employer needs precisely such a device, though not as powerful computing-wise as the combo of GoldFire and Aurora II. QL compatibility is actually one of the goals - time and time again, I have demonstrated that it is a very valuable tool, usually by writing small snippets of Sbasic on QPC2 to develop control algorithms for some of his hardware (and in this case I do mean hardware, as in motors, magnets and the like). To this end I now have on my table 10 68SZ328 fully 68k compatible 'systems on a chip' - commonly known as the last DragonBall CPU, used in Palm's last series of 68k based palm-pilots. This chip is still in production, and aside for not being extremely fast (it's a 66MHz 68000), it fits the bill quite nicely. The next project we are alrerady looking at is something similar using the new V4e Coldfires. The 68SZ328 'QL' will be a small 4-layer board slightly wider than the Aurora (say, the size of the printed Quanta mag). 16M of Flash (Replaced by 32M when larger chips become available) and 64M of RAM will come as standard. Also a VGA or TFT LCD interface, CF and MMC memory card slots, serial ports, and quite possibly USB and/or Ethernet. The intention is to make these available almost at cost to the QL community in exchange for porting SMSQ/E etc. First prototypes will probably also have a QL compatible expansion port, and all can be affixed to a small VGA resolution (640 x 480) TFT LCD. My only discomfort over Nasta's design is that he is extremely concerned about efficiency of space. Therefore, he's crammed an awful lot into a very small 6-layer PCB. Actually, it's 4 layer ;-) 6 Layer is not that much more expensive though - 15 to 20% has been quoted to me by the manufacturer. The only problem with said manufacturer is that it's the next country over, now part of the EU, which makes it necessary to go through rather complex customs procedures, but as my employer is looking at moving to multilayer boards anyway, it may be possible to do a 'where 4 can fit, the 5th can usually be easily shoed in' thing. Nasta is just too efficient for his own good ;) Looking back, I'm not really that efficient at all ;-( but I hope I will improve... BTW with recent experience in doing 2 layer boards running CPUs and RAM at 100MHz, I am convinced more than ever that ANYTHING can be fitted into 4 layers ;-) Oh, and one more thing - the same recent experiences have shown again that autorouters are still abysmal at doing any sort of efficient PCB design. At least the ones I can afford... Doing the routing manually, which took about a week, admittedly, I have managed to squeeze one 160x100mm 4-layer board and one 40x100mm 2 layer board (both autorouted) onto a single 120 x 70mm 2-layer board, almost 3x less area and about 7x lower cost of manufacture. Nasta PS, special note to TF: Aurora II and GF are routed with 8.333mil wide tracks and 8.333mil spacing - so not quite to romDisq standards but then, both sides are completely covered by components ;-) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] The hardware conflict...
On 25/11/04 at 13:18 Dave P wrote: Most elements of Nasta's Aurora II design are tried and tested, but the ethernet part is completely new. I would be inclined to suggest a short run of prototype ethernet only QL-standard expansion cards to go to developers. Once the hardware exists, it becomes an option to form a working group to produce drivers and a friendly API. We're looking at a few hundred pounds for the hardware, and hundreds-thousands of hours for the drivers... Dave Actually, the Ethernet part is integrated onto Qubide II, named EtherIDE. The IDE part is a slightly expanded and completely updated Qubide, and the Ethernet part is actually only a very small area on that borad - it was integrated literally because there was left-over space and cost of putting it over there equals cost of Ethernet chip plus magnetics plus connector. Because of this, it is easily 'transportable' onto a different project or on a stand-alone board. It is certainly possible to produce such board in small quantity and relatively cheaply (I am in fact looking into it right now). However, this supposes several things about the system in which it is to be used: 1) SGC 2) Aurora 3) Backplane And also, it relies on usage of the external interrupt pin (similar to superHermes). There are only a few people that would know how to use this, Lau Reeves foremost ;-) The hardware is 10BaseT, so 10 Mbit, fortunately, the manufacturer also makes a software compatible 100Mbit chip. One more thing connected with EtherIDE - it would actually be more straightforward to integrate a USB interface onto the Qubide II instead of Ethernet. Some time ago a Philips USB chip was discussed on this list. This uses a 16-bit data bus, and the only place this is currently available on a QL is on the IDE connector of a Qubide. The local Philips distributor has promised a few samples of this by the end of the year... N. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] QXL RAM
Dave P and Phoebus Dokos wrote: My question is regarding an overclocked QXL. Mine is currently at 33MHz but my 68040 is for 40 (therefore an 80 MHz crystal could be installed) but I do not know if the ram could take that! 70ns FPM memory will support 50 or 60MHz bus speeds with ease. If it's only running at 40MHz I would anticipate a large reduction in heat output and current drawn. 70ns should be fine for 33MHz. The problem here is not really the RAM but the GLUE chip on the QXL - it's already 'cheating' even at 20MHz, and uses passes through it's logic array to generate delays for RAM timing. As bus speed increases, differences from one GLUE to the next and differences in operating temperature make the timings more and more crytical, 60ns RAM just gives added leeway for timing mismatches courtesy of the GLUE chip. N. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] 68SZ328
Hi, Well, by the graces and capabilities of my employer I have managed to get a hold of 10 samples of the 68SZ328. The prise is about 17EUR plus VAT and carriage but I won't know for sure untill I get the info from the accountant as he ordered other things with them. As we discussed, he wants to build a small machine that would drive a CRT or LCD monitor, could be easily programmed, and would run some games. The idea of running it under SMSQ/E was discussed and he seems very interested in this as it's small and relaively easy to program. I've also roped in another 68k programmer that used to program Atari STs etc, and he is very impressed by the docs I gave him on SMSQ/E - he also downloaded the source. I plan to drag him by his heels if needed, to QL2004 later this year... he's the kind of guy that is capable of doing anything if only he finds it interesting ;-) I also have a small 640x480 TFT LCD, unfortunately only one but I think it would be sufficient for experimenting - a VGA output will be provided for sure, it's one fo the design goals to have it. The idea is to make a board about the size of the LCD that the LCD would bolt onto, and that would be the whole computer. Since I will have to design this board for work, I have discussed the possibility to make a number of them available to the QL community in return for work done on porting SMSQ/E, which I think would be beneficieal for all. The board itself is going to implement most if not all of the SZ functions - Most probably the largest possible RAM size would be used (that would be 2 banks of 32M, but depends on what chips I can get as the SZ uses a 16 bit bus), a decent size Flash ROM for booting from (2M at least, probably more depending on part prices), a MMC or SD memory card socket and probably USB will be included, ditto serial ports, VGA out, some sort of matrix keyboard (probably 8x8 like the original QLs, makes things easy), sound (most probably mono due to the limitations of the SZ), and anything else of use that comes to mind. The SZ literally has tons of functions... Not an easy board to make as the SZ has 196 pins on a small square chip, a 14x14 grid of ball contacts on a .8mm pitch. It is truly very small. The board will be 4 layers for sure, possibly 6. Graphics could be very easily made to be compatible with Aurora 256 color, and 16 color - the slight problem is that there is no capability to faithfully emulate old QL graphics but I think a screen emulation scheme could work, though it would only be for initial developement. Things to decide: * There is also a 16 bit color mode but it uses up a lot of the memory bandwidth for usable resolutions, which would slow down the CPU, so resolutins might be limited. This however remains to be tested experimentally. I'm leaning towards not using this mode as the CPU is after all only a 68000, even if clocked at 66MHz - it's alot of data to move around. * I'm not sure yet about implementing a QL compatible (or semi-compatible with some extensions) expansion port, but it might be usefull for developement purposes. If nothing else, one could put an old floppy controler on it to transfer files. Problems with this include accurately emulating QL timing (I think this could be done), and power considerations - the SZ is a 3.3V CPU. Additional buffer chips are a given for this, but they can be omitted together with the connector for apps where no expansion port is needed. An additional consideration is routing of the signal lines. * Use of one of the serial ports as IRDA - depends on the availability, price and power consumption of IRDA RX/TX modules. * Use of the SPI interface for, eg. a PS2 mouse port. Questions: software, power consumption... * USB - the SZ implements a USB slave device, which should not be terribly difficult to program a driver for, but as usual, doing a driver is a problem... * CF or IDE interface - very easy to do but again requires routing wires and extra buffer chips (fortunately, not many of them). Depends on PCB realestate, the SZ has so many functions that just providing connectors for all of them uses up masses of board space. Also, would require some changes in the drivers (either native SMSQ/E or Qubide). * Touch screen support - the SZ has it built in, and I will leave connectors for it, but supporting it will depend on wether I can get a touch screen panel of the right size without paying for it through the nose. The SZ also has some quite nice features for debugging, it can be boot-loaded from the serial port - a toolkit to do this could be easily written in Sbasic. The added advantage of using SMSQ/E is that my employer will certainly need a number of QPC licences as well as other QL software ;-) Oh, yes - another thing: my current email address will stop working sometime in September as the ISP has changed it's domain name, so instead of zeljkoDOTnastasicATzgDOTtelDOThr it will be zeljkoDOTnastasicATzgDOThinetDOThr. The latter already works, I just need
Re: [ql-users] 68SZ328
On 5.7.2004 at 15:51 Wolfgang Lenerz wrote: this would be a very intesresting topic to discuss during the Eindhoven meeting! By all means, try to get your guy there (and yourself, too!). I would certainly try to lend a hand at adapting SMSQE, if at all possible. Wolfgang Eh, sorry for this, the message was not intended for the list... but I suppose now that I've let some sort of cat out of the bag, any comment is welcome. Regarding this piece of hardware, I am trying to sort of skid around on the edge of a blade - trying to make it both what my employer wants it to be, as well as a product for the QL community. He is willing to pay for the hardware side of the developement, and this hardware could then be made available to the QL community essentially at cost, which is what the community needs. On the other hand my employer needs the expertise people of the community have regarding porting of the OS and some applications. The end product could then be marketed in several markets. Don't ask me about costs yet, I have no idea as it's all under developement. I know that boards are going to be made in neighbouring Slovenia, which is now part of the EU. General specs are as follows: * 66MHz 68SZ328 CPU (performance should be about 50% faster than SGC) * VGA monitor output (640 x 480 resolution or slightly over - theoretical limit is 1024x512 + there is a virtual screen feature) graphics in 256 colors (65536 is possible but only for lower resolutions due to memory bandwidth limitations) * Integrated small LCD display (6-7 diagonal) option to make a palm sized computer, stylus digitizer hardware included for touch sensitive displays. * 32 or 64M of RAM built in (not expandable) * 2M (at least) of Flash built in * MMC or SD flash card for storage (Sony Memory Stick is also possible but as this is less proliferant, more expensive, and larger, it will probably not be used) * 2 serial ports (or one serial and one IRDA) with high baud rate support. * Matrix keyboard (8x8, probably compatible with QL keyrow assignments) * USB device port (NOT host controller - the board would be a device to be connected to a host for data transfer) * Mono sound in/out * Real Time Clock * Low power * (possible extra features like a QL compatible expansion bus, CF or IDE port, parallel port, dimensions that make it fit a regular QL case, etc). ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] Nasta
On 11.4.2004 at 21:28 Marcel Kilgus wrote: I'm no hardware guy, but just for the sake of argument this chip looks like it could provide USB host functionality with a not too complex CPU interface. There's even a document with complete schematics that describes on how to interface it with a DragonBall CPU. http://www.semiconductors.philips.com/cgi-bin/pldb/pip/ISP1161a.html I have no clue how difficult the software side would be. Marcel To be honest, I have not looked at Philips for USB chips, having had rather nasty experiences recently with CAN bus chips - that let's make things better motto should really sometimes be, let's leave things alone... I had a quick look and downloaded the files - great tip. I had previously looked at the ISP1160 (which is only a host adapter, not a combined host / device), which can be used to provide USB functionality on an ISA card - a host-only adapter would already be sufficient. It may even be possible to connect this chip onto a regular QL. I will try to get some data on the cost and availability of the chip, unfortunately Philips does not offer an on-line quote for this chip either (just like they didn't for the 1160). As far as the software side goes, I think it would be extremely difficult if not impossible to put up a complete host stack under SMSQDOS without some serious changes to SMSQDOS (which it admittedly needs badly), as we again have a lack of clear layering - something that is a common thread from file systems down to TCP/IP. Let me make this clearer: it is not possible to cleanly have one driver interface with another and then operate as a driver stack (in this case 'driver' refers to the way SMSQDOS defines the term), which is paramount with things such as USB, where only a hardware interface is defined, and not it's ultimate function. To illustrate: the functions of a USB printer are rather different than the ones of a USB storage device, or a USB mouse, yet they all communicate using a USB interface, but all the possile functions cannot be integrated into one monolythic drivers, mostly because they are not known in advance. Because of this, with each new device, a 'driver stack' is created with pre-existing drivers, and new, device speciffic drivers, which interface with each other. Simplifying this down to SMSQDOS-speak: a complete USB driver stack has a hardware driver, and, a set of 'sub-drivers' if you will, that handle various classes of devices, and then a set od 'sub-sub drivers' that handle various devices of the same class, and then, we can have a 'sub-sub-sub driver', for instance to set up a file system on a suitable device within a suitable class, etc. Under SMSQDOS it is very difficult (AFAIK impossible cleanly) for multiple drivers to address a single piece of hardware, without some sort of arbitrating mechanism 'on the side' which operates unbeknownst to the OS and just between the drivers themselves. Alternatively, a hardware abstraction driver could be made, that provides a multiple access virtual device, to which the various other drivers then interface, and manages the arbitration as to which drivers can do what and when to the hardware or each other - although this is possible, it is subject to all sorts of silly limitations, as soon as a directory device enters the picture (slaving, DEFBs, name lengths etc). All that being said, it may well be possible to _relatively_ simply interface to a single class of devices, for instance, USB storage devices such as USB Flash keys or hard drives, but probably NOT USB flash card readers per se. This is because a 'stack' of sorts for a speciffic class of devices can be 'fused together' into a single device driver, that could operate under the confines of SMSQDOS, in it's current state. Even so, there would be no guarantees that every generic device of the storage class would work, so if you go out and just buy a USB Flash key, wether it works or not may depend on what kind of internal circuitry it has. ___ QL-Users Mailing List
Re: [ql-users] Nasta
Now I get to be the subject on an email list ;-) - well, there is always that first time, i suppose ;-) People monitoring this list will have noteced that my posts are few and far between these days - for two reasons: one, I have two jobs, and two, I have the same problem with emails Jochen seems to have, but even worse. As my ISP seems to be an originator of SPAM, many ohers simply ignore emails sent from it. I am rather delighted to see that the last message got through to the list, since it was changed over, but I have no idea how long this will last. As one would immagine, it is most frustrating to be only able to read emails, AND have 95% of them be SPAM lately (I get 100 emails a day). Regarding a formal business proposal to Quanta, this will be complicated for me without an intermediary. Let me remind you that I live in Croatia now, which is not a part of the EU (and currently regarded far too backward a country to become a member, apparently), which means that proposing any kind of business that has to deal with trans-border stuff is a real problem. If I were to, for instance, detail the channels that I would use to procure parts, most would definitely find them arcane (to put it mildly) but that is how things work here. Let me make it clearer - I _can_ get practically any part I want, assuming I can talk (twist arms and necks etc) of the suppliers to get me these in small quantity, and am willing to wait an indeterminate amount of time - hardly something that would seem sound in a formal business proposal. Secondly, some services have to be procured elsewhere - for instance, there are a gazzilion facilities that can produce quality two-layer PCBs in Croatia at very reasonable prices, but none that do multilayer boards - for that I have to go to Slovenia, which will, sometime in the next 3 months, become an EU member, at which point any arrangements made may become a bit more complex - or simpler, the fact is, I don't know and no-one else seems to, either (list members from countries that use the Euro will no doubt remember the price fluctuations on nearly all markets when the Euro changeover took place - a similar thing will happen in Slovenia). Most of the market for a product such as GoldFire is in the UK, which, even while being a member of the EU has it's own rules of sorts when finances are concerned, and the rest of the market is distributet amongst other EU countries and the US. For me, this means that I have to go through hoops to import parts which will be exported as a product, all while not being a company, but a private individual. In order to do so, I would have to find an intermediary here, which makes things far more complicated. Last but not least, I have two jobs at the moment, which for obvious reasons (such as being able to afford a living at least at the very basic food and lodging level) have to take precedence. Hardly a situation that makes it possible to just sit down and write a formal business proposal, and have it not sound insane... Fortunately, things are not as dark as they may seem. Due to the arrangement I have at work, I can use the resources of my employer with regards to parts and service sourcing, at their cost. Secondly, my employer has a keen interest in ColdFire based single-board computers. In fact, we have done some preliminary discussions on two possible projects, one based on the V4 coldfire, and another, based on the 68VZ328 Dragonball CPU (the latter is fully 68k compatible and runs at 66MHz, and includes a ton of peripherals on-chip, including a LCD/CRT controller). For the people that have suggested giving me room and board as it were, things are a bit more complex than that at the moment. I can do the developement where I am now, however, a modest amount of cash and a rather larger amount of time is necessary for this. Nasty question number 1 (For Nasta): To what stage of physical hardware has Goldfire developed, or is it still all on paper? This question is not as nasty as much as it stems from a misconception. The answer comes in two parts: 1) Apart from a set of parts for prototypes (and some parts that I have in sufficient numbers for a 50 piece production run), GoldFire is still only 'on paper' or rather as designs and simulations in relevant CAD programs, plus reference documentation. 2) There is no way to breadboard* this design, so 99.95% of the developement is carried out 'virtually' - it is impossible to produce a true prototype design without it being so close to the final design to be virtually indistinguishable, or, an attempt to make it as a 'breadboard' prototype would result in a non-functional design because of the required technology to insure signal integrity at such speeds. * Breadboarding is the process of completing a design on a 'breadboard', i.e. a 'universal' PCB that is then hand-wired point to point. Chips used on the GoldFire cannot be used in this manner with any reasonable expectations of proper functionality,
