Re: [ql-users] Q40 Problem
I was wondering if someone might be able to come up with a permanent solution ...maybe there are some spare [VRAM] chips with longer pins IIRC these are 256k x 4bit 80ns VRAMs. I have a number of these, types: OKI 514262-80Z and OKI 514252-80Z. There is a difference, IIRC, the first type has some sort of integrated unit that facilitates bit-blit and color fill operations, but as far as I remember, it is downwards compatible with the standard which should be the 514252. The Q40 doesnt use this unit anyway. I've got 16 of each, Q40 uses 8 - I have 8 brand new 514262s, the rest are recycled but with full length pins. I could probably be persuaded to part with them ;-) The problem with these is probably the typical problem with recycled chips in sockets - the pins are not cleaned from the remaining solder, they effectively become larger because of the extra solder plating. This puts extra strain on the spring loaded contacts in the socket. Couple that with thermal cycling, where parts dilate and then shrink back every time they go through a power on / power off cycle, and the socket becomes progressively looser, but the solder part of the pin gets 'worn down' as it is softer than the actual pin. The result is lack of contact - in some extreme cases chips have been known to pop out of sockets (This sometimes happens even on new chips with badly designed sockets). The result can sometimes be that even brand new chips will not fit any more - as the brand new ones will have pins that are too thin to make contact! If such a situation arises, the quick and easy solution is to carefully solder the chips into the sockets - chip by chip, so you can get at all the pins. In case of a chip failure, this will not make much of a difference - the socket failed in any case, so the only difference is wether there is a bad chip soldered into a bad socket, or it's only the bad socket - in either case the socket has to be desoldered, and thrown away, with or without the chip. As Tony well knows from superHermes, turned pins in professional sockets DO solder quite easily even from the wrong end ;-) Nasta
Re: [ql-users] Quanta
I for one would use a QuBide with another IDE slot on it. John Gilpin Quanta Treasurer. Actually, the replacement would have 3 IDE slots total ;-) Nasta
Re: [ql-users] In search for an Ethernet card for my Q60
On 8/9/2003 at 3:25 AM Tony Firshman wrote: I can't see any mention of 'pnp' in the datasheet. Ah there is a jumper - 'jp1' marked 'default' to p39 EECONFIG - load from EEPROM. Note pins 50..58 (CA0..7), 40..48 (CB0..7), 22..31 (CC0..7) and 39 (EECONFIG), in the table on page 6. The first three sets of 8 are actually the external RAM/ROM data and address lines. A pull-up to any of these pins sets the corresponding bit of the registers inside the AT/Lantic to 1, pins left unconnected remain at 0. EECONFIG needs to be puled high in order for the AT/Lantic to use the parameters from the EEPROM rather than the said configuration pins, there is a small serial EEPROM on the board for this purpose. I would bet the jumper disables it by pulling EECONFIG low. The EEPROM also stores other data, such as the 48 bit 'unique' MAC address, which is the address of the actual ethernet node the chip is supposed to implement. Fortunately, this address can be loaded/changed later on by a driver, so the EEPROM is not really required as long as the configuration pins are set properly. Now go to page 14 and reads under '4.4 Jumpered and jumperless operation support', speciffically 'Fully jumpered configuration'. Page 25 describes in detail the functions of the bits in configuration registers A, B, C. I assume that the NE2000 compatible / AT/Lantic board needs to be set to IO operation, i.e. NOT memory mapped. This is the configuration I used for the QL design. Special attention is needed to set the interrupt mode properly. IIRC, most AT/Lantic boards I've seen use the 'coded' option, normally a GAL 16V8 or PAL 16L8 is used as the decoder, see if you can locate it on the board.
Re: [ql-users] More about SMSQ/E v3.01 on SGC (and QXL)
On 8/8/2003 at 4:00 AM Thierry Godefroy wrote: I conclude from the above that it must be a problem in the initialization code of SMSQ/E v2.98+ as everything works just fine with v2.91. I had a quick look to the sources, and if looks like SMSQ/E v3.01 checks for ROMs at addresses $C000 (ROM slot) and $4C (inclusive) to $50 (exclusive) with $4000 bytes (16Kb) increments. Following the instructions in the Aurora manual, my Qubide is configured to show its ROM from the base address of $4FC000, so it -should- be detected, like should be the ROMdisq (address $C000). BUT: I seem to remember that SGC and Aurora are using shadowing mechanisms, so my question is: are those addresses valid at boot time ? (Nasta, are you with us ? Three knocks for 'yes', two for 'no', please ! ;-) OK, first the 3 knocks requested: knock, knock, knock! SGC uses shadowing only in the screen areas, so that would be $2 to $2, or $27FFF if screen 2 is disabled. Aurora basically follows what the SGC does, but the old screen areas also appear in the new screen area, that would be at $4C. It is worth noting that the Aurora actually has 256k of screen RAM, but normally only 240k is used - i.e. the block at $4FC000 to $4F is not used to display an image, but is there and acts as RAM, as long as nothing else is using those addresses. Normally, those addresses would be used by a Qubide set to $FC000. Without a Qubide there, one could actually load a 16k image of an EPROM and it should get recognised as an EPROM when the OS is restarted (or an OS is subsequently loaded and started as in the case of SMSQ/E). This is the only hardware mechnism that I can think of that could prove to be problematic, but I think it is highly unlikely. If a Qubide is connected, it would be there from the start and should get recognised and initialised. That being said, the Qubide code first copies itself into RAM then continues execution. This could potentially be a problem if the cache settings are incorrect. Well, that's all for now... I was about to fiddle with the hard disk driver of SMSQ/E so to allow non-blocking ATAPI commands on my CD-ROM driver (there's a bug in SMSQ/E preventing to delay the ATAPI queue execution, for example when the CD-ROM spins up), but I'll wait until I find a way to have an homogoneous setting on at least both the Q60 and the SGC. Thierry, I have a question - would it be possible to adapt the SMSQ/E hard disk driver to the Qubide? This way there could be a standard of sorts, especially since the Qubide driver is no longer maintained, and sources are not available... The reason you are getting asked is of course being famous for writing the CD ROM driver ;-) N.
Re: [ql-users] In search for an Ethernet card for my Q60
On 8/8/2003 at 2:55 PM Phoebus R. Dokos wrote: I have an ISA NE2000plus3 pcb marked Microdyne 1996 but no jumpers. It uses AT/LANTIC DP83905AVQB chip. Btw: Theoretically the 15D connector is the Ethernet connector and the Ethernet connector (BNC) is called Cheapernet (later on 10Base2) The D15 is also called AUI. Both 10BaseT and 10Base2, as well as other attachments standards can be derived from it, for instance fiber optic. With 100Mbit ethernet, it became deprecated in favour of twisted pair, i.e. the MAU (Media Attachment Unit, converts 'Ethernet' to a given media, copper, fiber, wireless) is now integrated into the chips themselves. The AT/Lantic only has an integrated 10BaseT, the 10Base2 is actually an extra chip with some passive components driven a small DC-DC converter. The AT/Lantic chip has, I believe, a non-PNP mode as well, it is activated by putting pull-up (or was it pull down?) resistors onto certain pins of the chip - these pins normally drive the buffer RAM and the Boot ROM data and address lines - if there is a Boot ROM socket, it should be possible to disable PnP quite easily by soldering resistors onto the socket. It is very probable that the card actually has spaces for surface mount resistors in the required places. National Semi still has data for the DP83905 on their web site, and IIRC also a reference design, most of the cards using this chip are almost complete copies of the reference design! When I originally thought of designing an ethernet IF for the QL, I wanted to use this chip. As a matter of fact, the design evolved right to the end, it was just never made - I even have a PCB designed for it, it's a 2-layer job about the size of the Qubide, with no through-connector.
Re: [ql-users] EPROM Images
*** REPLY SEPARATOR *** On 6/23/2003 at 6:41 PM Marcel Kilgus wrote: ZN wrote: For the ROM slot? IIRC it only has 16 address lines, i.e. yes, it can only have 16kb. That would be 14 address lines, addressing 16384 bytes i.e. 16k. Marcel, you are getting old ;-) True ;-) Ah well, somehow I calculated $C000 + $4000 = $1 = 16 address lines. Haven't played with all the ROM stuff for almost a decade now, though. So how is it in reality? 64k beginning at $C000 or how is the port mapped? Marcel Well, there are actually all 16 lines, and a ROM select line (high). It's just that the 14 lower bits are fed directly to the EPROM in a standard cartridge. A third of a 74LS10 (tripple three input NAND gate) is used to provide an active low chip select by detecting A14, A15 and ROM select high. SInce ROM select is high whenever the first 64k (*) is accessed, this maps the EPROM into $C000 to $. This also privides a clue to moving the complete ROM area onto the ROM slot. In this case, a 64k (27(C)512) EPROM can be used to hold 48k of the original ROM plus an image of whatever is to go into the ROM slot (normally TK2, I suppose). All 16 address lines are then routed to the EPROM chip. The ROM select is only inverted, as EPROMs have an active low chip select input. The original ROMs MUST be removed. The big omission on the ROM slot is a 'write' signal. Clever hardware can be used to 'remember' the state of the lower 8 address lines when a read is done from an area (obviously at least 256 bytes in size) set aside - the read data is normally ignored, as the purpose was only to capture the state of the address lines and later use them as data - then this data is written somewhere by the hardware. The most notable example of this is Romdisq, although other hardware used the same trick (there was a Kempston printer interface, I think, that used this, as well as the original Miracle hard disk).
Re: [ql-users] efficient buffer size
On 6/21/2003 at 11:35 PM Lau wrote: Back to my earlier mention of caching... hard drives and their controllers do caching as well. I'm not certain if they do read-ahead caching. In short, yes. Even older IDE drives with sufficient buffer memory at least attempt to always read in the whole track if given time (no requests for sectors from another track within the time needed for a full revolution). However, the definition of a 'track' can vary - logical tracks (as addressed by the CPU) have very little to do with the physycal actuality, as most drives since the ra of 40Mb drives have constant linear bit density - i.e. outer tracks, being of a larger circumference, have more sectors. The drive does the translation into a uniform sector per track topology. Most drives do read ahead in terms of physical tracks, but in some cases (such as small buffers or odd translation schemes) will work in terms of logical tracks. In any case, the actual mechanism is hardly important and the implementation is is left to the drive manufacturer.
Re: [ql-users] Dexter, paging Dexter (Dave P.)
Pardon me folks, while I usurp the list once more - I promise to be short... On 10/02/03 at 15:00 Dexter Newman wrote: [GF parts] They're all in a box ready for you. I could either ship them to you here or after your move - whichever is convenient for you. Dave - I don't seem to have a working email address and phone # for you any more... It is time to get those parts on my way if possible. I will be leaving on the 31st. My phone is 704 5971283, email zn/at/carolina/dot/rr/dot/com - could you please call me or email me a phone # I can call you at and a convenient time, so we can arrange this? Thanks! Nasta
Re: [ql-users] Altera EP 1810 chipa, AKA GC/SGC INGOT, QXL Glue
There is a small number of these, apparently blank, on eBay at the moment 26 I think... there are a few GCs, SGCs, QXLs that could use these... Date of manufacture is the critical thing, as I am _sure_ you know. My working SGC is date stamped C9602. I reckon any later date stamp will not work. Roy Wood will know more. Yes, I know - I can't discern the date code from the pictures provided, so I emailed the seller and am awaiting an answer. What I can see looks like BGC87... but that sounds FAR to early for the -20 speed grade. It could be a 91... difficult to tell. Auction number 3105900311 Nasta
[ql-users] Altera EP 1810 chipa, AKA GC/SGC INGOT, QXL Glue
There is a small number of these, apparently blank, on eBay at the moment - 26 I think. Just checking if anyone involved with GC/SGC/QXL is bidding on these, and if so, I won't so we don't bid against each other. Part number is EP1810LC-20, without the problematic A at the end! I believe there are a few GCs, SGCs, QXLs that could use these... Nasta
Re: [ql-users] WMAN progress
On 22/11/02 at 01:40 Phoebus Dokos wrote: Since you wanted more... take a look on what I am helping Marcel create ;-) Phoebus I don't mind :-) it looks very nice. For one thing, better choice of colors (no offense, Marcel :-) ). Nasta
Re: RE: [ql-users] One box or two
On 18/11/02 at 14:27 Colin Parsons wrote: What about a 3.1 Ghz PC Considering that it would still just barely beat the Q60 I think you would be better off with a Q60 since the whole thing costs less than the 3.1GHz CPU alone - assuming you find one that will actually run at that speed. Nasta
Re: [ql-users] Memory
On 14/11/02 at 11:42 Tony Firshman wrote: When one does a reboot with SMSQ/E image file (using LRESPR), I wonder whether the following might work: No it wouldn't. SMSQ/E takes over and reinitializes everything from scratch. Nasta
Re: [ql-users] Qeymail, last call for suggestions...
[Qeymail] Darn, I can't keep up with you all even with a broadband connection - and to think that a few weeks ago people were complaining the list was dead... IIRC there is a serious limitiation in SOME file systems, and this is a _TOTAL_ number of files on a drive, which, IIRC is 65535 (if coded correctly) and 32767 if the author forgot to use unsigned 16-bit integers. The problem is endemic to all purely FAT based systems because the structure is based on a table where each entry means physical sector (index in table) is sector X of file Y - where both X and Y are of some predetermined size - 12 bits on floppy, 16 on hard drive. The same structure is inherited into directories, because you want to alow one directory to use the whole available number of files, if needed. But, there is always a limit. I am not sure what it is for TTs HDD (and QXL.win) driver, though. For a file organisation, I would vote for inbox = directory, email = file. Basically, keep the inbox organisation in the index file - this includes any sub-folders in it, deleted files, compressed files, etc, etc. Directory and file names should obviously be kept short (36 characters to a path + name limit...), so I suppose the file names should be somehow 'hashed' or encoded from a date or just have an ever increasing number. One could encode a 32-bit number plus a few extra flag bits into 6 bit + offset ASCII. This would give us 10 character names. The index file would hold the actual structure (which email file goes where). The user could then have an option to periodically physically delete all files marked as deleted. Also, the number of files should be kept to a sane number, once this is reached, the user could be prompted to compress older files - these could simply be zipped into one larger file. This would then also have an encoded name, which would, for example, reference the newest message in the archive (for search purposes). Finally: a small 'I told you so' for the people who keep saying the file system is just fine and that 36 characters are enough. Funny how this can turn out to be a limitation even for a 'simple' application, isn't it? I TOLD YOU SO! Nasta
Re: [ql-users] Q-Emulator 2
[Jonathon Oakley] I believe he is one of the people who seems to have dropped off the face of the earth? IIRC he was at the Bielefeld meeting all those years ago... Nasta
Re: [ql-users] Qeymail, last call for suggestions...
On 12/11/02 at 14:03 Dave P wrote: The bitfield will actually be an integer, but I expressed it in this example as bits: 0 Received (1=sent with this client 0=sent with any other client) 1 Read 2 Reply sent 3 Forwarded 4 - reserved 5 - reserved 6 Archived 7 Deleted [timeasinteger] will be the sent timestamp. timezone will allow the correct time to be displayed in the client. Subject is, well :o) If there's anything else that you think would be useful to have in the index, please say so now, though it will be quite easy to change later. 'Has attachment' 'Attachment removed' Every once in a while sort by attachment is VERY useful (as in: someone sent me a file, where is it?). Attachment removed is also interesting in case you want to only archive the actual messages without attachments or just remove attachments after a while to save space. N.
Re: [ql-users] Qeymail, last call for suggestions...
On 12/11/02 at 15:57 Dave P wrote: Thanks Nasta. Nice to see you becoming a useful member of society again ;P Why, thank you! I think... N.
Re: [ql-users] Ooo! What's happened
On 09/11/02 at 15:20 dndsystems1 wrote: QUICK! QUICK! WOLFYS SENT ME AN EMAIL. Dennis - DD Systems Oh, please - everyone has been waiting for this issue to be resolved. Now that he has sent you an email, I sincerely hope it will, and OFF LIST. The forst thing that popped in my mind after I read this was 'how old are you'? I'm sure, not a way you'd like to be thought about. Nasta
Re: [ql-users] Ooo! What's happened
On 09/11/02 at 14:26 Phoebus Dokos wrote: hehe Nasta, you cannot deny however that in reality we're all still boys with expensive toys :-) (And crazy hobbies... I bet most of our wives agree on that) The key to it is not to have a wife ;-) A friend of mine used to say that you have a counter argument if she has her own set of toys. Then he got married and had all the proof it wasn't so :-) P.S. I will be sending you that thing pretty soon.. .Are the QubIDEs ready by any chance? (One stone, two birds with this mail) Not yet - but I will make the effort. Let me eek the most efficiency out of my one stone too: The Aurora can only be used un a US TV with component input. The composite output on the Aurora is somposite monoshrome, not color - as you can see the PAL/NTSC modulator chip is not on it. It is however possible to get an external modulator, but since Aurora is 50Hz and not 60Hz like US TVs, it's anyone's guess as to how the TV will interpret this. A way around the problem may be an external scan conversion box, VGA to TV. If you need one, I have it and can send it to you. This should be able to convert Aurora output set to VGA into something viewable on a US TV set. Metadriver and associated concept answers I will have to leave for some other time - busy week end. Would appreciate a phone call if you have the time (hopefully shorter this time :-) ) as I can keep working while we are talking. N.
Re: [ql-users] SMSQ/E License
On 07/11/02 at 17:07 Dave P wrote: The issue I take with it is this notion that all versions of SMSQ/E must be identical. I think this is not in SMSQ/E's best interest because it discourages development. For example, I think it is good for a version to add a feature that may not be supported by other platforms, *as long as it is an addition*, and the software style guide states that if the feature is used in software released for all platforms, the equivalent functionality should be included (if possible) for other platforms too. For example, say a machine is released that requires different code to operate an IDE interface. That version should be allowed to exclude code which is simply not relevant, like microdrive-related code, if microdrives could never be attached to the machine. (this may be a bad example) Then what you really want to say in the licence would be that additions to SMSQ/E to add a feature of capability to one platform will not be accepted if it may seriously hinder or even prevent adding an equivalent feature or capability on another. Obviously, this excludes all platforms where such feature simply makes on sense or is impossible (by design - leack of need), but does at least suggest some form of forethought, so that we don't get 'my way or the highway' style features. This breeds tremenodous problems with writing applications and further additions to SMSQ/E. Nasta
Re: [ql-users] 10BaseT Ethernet on the Q40/And of course a stupid question :-)
On 03/11/02 at 17:57 Öïßâïò Ñ. Íôüêïò wrote: In 10 minutes I'll be the proud owner of a Q40 (Yipe!!! :-) which begs the question anyone knows of a 10BaseT Ethernet ISA adapter that works with it? I don't want to get a 10Base2 one and then have to find a Twisted Pair converter for the coaxial. No, just look for one that has all the options. Internally it's really the same thing as far as the Ethernet chip is concerned. If you can't find one, i think I can get you an ATlantic (NE2000) compatible with both 10Base2 and 10BaseT. If the software doesn't do it, IIRC this chip has a pin option (pull up/down) that forces the media attachment option. Also, does anybody have info on how the QXL talks to the ISA bus? It would be interesting (to say the least) to put the QXL there and use it together with the Q40 ;- Thierry Godefroy knows, I'm sure Nasta
Re: [ql-users] Hardware platforms
On 29/10/02 at 22:15 Dave P wrote: OMG! I know this is a little OT, but guess what new paperwork they just introduced at work. TPS Reports! TPS Reports! PS: See: Office Space Well, look out for the evaluators and optimizers (= consultants) I've recently visited friends in Greenville SC, they work at Fluor-Daniel, my would-be employers, before 9/11, that is. Apparently management has been poring through every TRS employee (Temporary Recruitment Service), which is what I would have been, apparently figuring to cut as many jobs as they can. So there you have it, even if I had gotten that job, they would probably throw me out. So I'd be more or less in the trouble I'm in right now... Nasta
RE: [ql-users] Hardware platforms
On 28/10/02 at 18:30 Dave P wrote: Maybe I wasn't clear... :o) ... If we had a really compact embedded board with serial/IR keyboard/ programming in BASIC (a bit like a super BASIC STAMP module, but more powerful ;) it could sell by the bucketload. PRECISELY This is THE market for QL-like hardware and SMSQ. I have looked through various offerings in this area and even with Mot. (in all their 'wisdom') making undue problems with 68k/MCF availability, a 'QL-stamp' would win hands down just on the strength of (a) Sbasic (b) multitasking. Heck, I would be buying them right now. It's only a pity that Mot. decided to deprive us of the component most suited for a 'QL-stamp' - the 68306 (IIRC). The closest to it right now are the Dragonballs (68328 in all it's versions). There is one V2 coldfire that could do the trick too, and although not completely compatible with 68k, this is a case where it would not be a great problem as it would not run any of the traditional QL apps (so the SMSQ/QDOS/Minerva source could just be recompiled via microAPL's cross-compiler), but in this case the benefit to the community is not very big, unless a way is found to funnel the financial proceeds back into it. Nasta
Re: [ql-users] Hardware platforms
On 26/10/02 at 00:31 Stephen Meech wrote: C'mon you guys, who's going to buy this thing? Enthusiasts like you will use existing solutions. The rest of us, who are now using PCs for their day to day computing retain an occasional interest and are best served by cheap emulators that will run on the relatively cheap hardware that is already taking up space on our desks Well, then it seems you have everything you need - hence you can go back to using it, as this discussion doesn't seem to concern you. If the sales were the motivation behind designing QL hardware, it would have stopped somewhere around 1990 or so. Just my opinion. Nasta
Re: [ql-users] Linux on Q40
On 25/09/02 at 20:03 Dave P wrote: On Wed, 25 Sep 2002, Jonathan Dent wrote: I'll need the SGC Aurora IDE/Ethernet interface before I can work on pppoe but maybe a more intelligent ADSL router/hub would be a simpler solution. (if more expensive) That's Nasta's baby. Nasta, I have these parts for you. Want them? :o) Sorry for not jumping in here, I was having a bit of an email problem last week, not a good thing when you need to get and send eBay related email, and there's money on the line - so now I'm catching up with the list, and deleting the Lookout Distress related messages (best fix for it = uninstall). Anyway: I was thinking of trying to make a tiny proto version of the ethernet, that would plug onto an Aurora ROM port. So far, however, I have yet to get my printer to print something that would actually produce a printed circuit of that density (single layer may be fine for this). I still have the few 10BaseT transformers for prototyping, so for now Dave keeps the parts ;-) Nasta
Re: [ql-users] Weird problems with Aurora/SGC
On 09/09/02 at 18:19 Phoebus Dokos wrote: Does the problem happen without Qubide? Yep it does... Well, then the next step is, do you have a regular QL? Nasta
Re: [ql-users] SGC and SMSQ/E on ROM for the Aurora
On 30/08/02 at 22:22 Phoebus Dokos wrote: Hello all, Since I have finally returned its about time, I ask one of my famous crazy set of questions ;-) Here goes: 1. Have anybody successfully overclocked the SGC? If yes to which freq.? Yes, I have, but only to 25MHz - because I only had oscillators for less or equal to that, which could fit the space. It worked just fine, with the exception of the floppy controller which is normally clocked from the 24MHz oscillator. However, I may be persuaded to try it again - after all, currently the SGC is running without a floppy, connected to an Aurora through a Qubide with a CF card on it. This means all the traditional problems with 8301 timing and floppy access do not apply. And - I have many more oscillators to try :-) BTW Phoebus, your Qubide is still here. I will be (with some luck) sending it over next week with a new set of GALs, these will be a bit experimental, so I will include a pair of the standard V2 GALs as well. P.S. And oh! being in the subject of crazy stuff... anyone had any ideas on how to attach a QXL-II on a Aurora ? (That would be a nice adaptor;-) QL bus to ISA :-) It should not be to difficult, actually, assuming one finds the space. In fact, it would be easyest to attach it to the ROM slot, as strange as that sounds. Regarding your question about activity indication for the ROM slot, it cannot be done easily (i.e. without at least one chip and use of a soldering iron :-) ). Nasta
Re: [ql-users] SGC and SMSQ/E on ROM for the Aurora
On 30/08/02 at 22:22 Phoebus Dokos wrote: 1. Have anybody successfully overclocked the SGC? If yes to which freq.? Yes, I have, but only to 25MHz - because I only had oscillators for less or equal to that, which could fit the space... I may be persuaded to try it again Define MAY be persuaded := Ah, as one good quote goes for one bad movie: time is the fire in which we burn... If I get the time during the long week-end, I may have some results for you. BTW Phoebus, your Qubide is still here. I will be (with some luck) sending it over next week with a new set of GALs, these will be a bit experimental, so I will include a pair of the standard V2 GALs as well. Oh with the new logic you were talking about a while back :-) Niic! just on time to attach to my new toy :-) A long time ago, when the lrespr version of the driver came out, Phil Borman also mentioned locations that needed to be patched if Qubide was set to an address different than the ROM port. If you have the lrespr version somewhere, I would apreciate an email with it attached :-) P.S. And oh! being in the subject of crazy stuff... anyone had any ideas on how to attach a QXL-II on a Aurora ? (That would be a nice adaptor;-) QL bus to ISA :-) It should not be to difficult, actually, assuming one finds the space. In fact, it would be easyest to attach it to the ROM slot, as strange as that sounds. Someone mentioned the Miracle HDD interface. It would work with modifications because it decodes different addresses that the ones QXLs normally use. Another possibility would be the Falkenburg interface, that one also used a QL to ISA (8-bit) adapter. It would probably also need some changes. Would the Aurora initialize without the original processor of the SGC? Or would that be a case of trying a boot up then discard use of the 68008FN on the Aurora instead of an SGC in anticipation of the GF? I don't understand the question? The Aurora has no CPU on board and relies on the SGC to supply one (or, more correctly, an emulation). A 68008FN (or even the regular one) would work just fine as a regular 'standard' QL without MDVs given the correct connection of the 68008 to the bus. A proper decoder would make it look like a 256kB QL of sorts. Well in that case I would rather conserve my skills in soldering (emphasis on the quotes) to realizing that 68008FN + 4 Meg memory upgrade you proposed way back (of course due to my crash you would have to send me again that little text diagram you had sent the list if that's not too much trouble :-)) If I find it! But that was based on a regular 68008 QL as a simple 512k memory expansion. Someone was actually selling suitable 512k chips on eBay a while ago (on three occasions, different versions). The DIP verisions which are nice and large and easily soldered, seem to be very sought after as 10 'recycled' ones went for over $30. OTOH, SO surface mount ones went for $63 for 40 brand new chips. For the 68008FN the ideal solution would be taking two dynamic RAMs off an old 72-pin SIMM of 16MB capacity (the ones with 8 chips). The interfacing logic is however far more complicated and would best be fitted into a small programmable logic chip - for instance, along with the decode for a CF card and a transcode of addresses so everything appears where expected by the OS. Even with static RAM it would not be much simpler... Nasta
Re: [ql-users] PC Monitor Lead
On 24/07/02 at 13:06 Marcel Kilgus wrote: ZN wrote: Regrading portrait monitors, oddly enough some of the newest ATI Radeon cards for the PC will generate a 90 deg rotated picture, and mirrored, too. Does it do it in hardware? I quite like using my TFT in portrait mode, but the translation software slows down some things too much (like QPC). Software, I'm almost sure - I'm not certain about overlays as there is so much involved with getting them on the screen in the first place, it might well do that in hardware. I will try it when I have some time. It's not perfect - for instance, when I accidentally activated the option, the window that did that ended up off screen. I quessed it wasx one of those 'accept: yes/no' boxes so pressed esc, and luckily it came went back to normal. IF your TFT has portrait mode (I can see how this can be great for programming, as listings tend to be much longer than they are wide :-) ), you may want to investigate operation without translation. TFT horizontal and vertical drivers are literally the same kind of chip - they have pins to tell them which way to work. Some TFT tilt monitors are aware of this and use the feature, but require the graphics card to be capable of generating a portrait style resolution (e.g. 768x1024 instead of 1024x768). In other words, it keeps scanning left to right even in the portrait position, not bottom to top as when transaltion is done in software and the screen tipped. Monitors that do this will attempt to display a (sometimes squashed) lanscape picture across the middle of the screen (with big black borders on top and bottom) when rotated (or otherwise set) in portrait mode, without the computer knowing it. Nasta
Re: [ql-users] PC Monitor Lead
On 23/07/02 at 21:54 Darren Branagh wrote: Are you sure it worked with a PC rich? Reason I ask is the only monitors I have ever come across like this were ones made by Radius for the Apple Mac. They were popular in Newspaper offices etc. as it was better for desktop pulishing and artwork - which is were the Mac reigns. The Mac also uses a 25 way connector (on older models). Old Mac connector is 15 pin D (similar to PC joystick) not 25. Regarding the monitor in question, I think I had one of these a long while ago. IIRC it's a monochrome model with some odd resolution like 720 x 800. It's intended to work with two graphics cards, a monochrome (Hercules) graphics card (remember those?) and a special portrait graphics card that should come with the monitor. The monochrome one is connected to the D9 connector and is used only in a compatibility mode, showing a picture about half vertical size and full horizontal size in the middle of the screen. The special card is connected to the D25 connector and when active (needs special driver), generates the full portrait picture. Regrading portrait monitors, oddly enough some of the newest ATI Radeon cards for the PC will generate a 90 deg rotated picture, and mirrored, too. This would of course require you to tip your monitor over to the side. I just installed one for a friend here and activated the option by accident - and got a surprise. Nasta
Re: [ql-users] SMSQ Source upgrading, assembling.
On 10/07/02 at 09:58 [EMAIL PROTECTED] wrote: George - I think that you are missing the point here. ... However, the fact remains that a lot of SMSQ/E developers use computers/emulators which do not support 68020+ and therefore cannot run GWASS to write the code... How much of an effort would it be to change GWASS itself to run on a 68000 or 68008 based QL?? 68000 = 68008 as far as software goes (except of course addressing capability but that is up to the user to handle properly). It would be a GREAT benefit to have an assembler package that is coded using only 68000 (or even reduced 68000) instructions, that never the less can handle 68020+, and more. This is of course my perspective as a hardware designer - knowing that Motorola has seen fit to (try to) kill off 68k, and force ColdFire on ex-68k developers. Things are getting better as far as the differences between CF and 68k with every new CF generation, but the fact remains, requiring 68020+ for a piece of software may be a 'built-in' dead end - even the 68060 is technically obsolete (actually, the trem is 'end of life'). Assuming the community still exists at that point, it's only a matter of time until a CF based QL happens. Nasta
Re: [ql-users] ED Disks
On 02/07/02 at 00:52 Roy Wood wrote: By the way. I have also just acquired about 13 boxes of brand new IBM ED disks in sealed plastic disk boxes of 10 if anyone needs them. The last of the stock I could find. Roy, would it be possible for you to send one or two disks my way - I have an IBM ED drive (and ways to cheaply get more) that I would like to connectto the QL but it has no jumpers. The only way to figure out wether ED works is using an ED disk and connecting it to a PC first, but I have no ED disks. Experiments with 'false' ED (HD with hole drilled) did not work so far... :-( Thanks, Nasta
Re: [ql-users] Just another idea
OK, now that's really ENOUGH. Could we please keep testimony about Peter Graf's character off the list (or on the QL chat list?) - and I mean ALL sides!!! I don't think any of this is relevant to SMSQ/E being licenced one way or the other. The fact of the matter is, DD and P.G. can do business with the current licence. If their (undisclosed as far as I can tell) developer(s?) will not develop under it, they have to take it up with their developers, or ask other people that will develop under the current licence - not require the licence to be changed for them. The more so, since once they can all get the source in their hands, most of the problems we have all read so many objections about, can be worked around, or become no-issues with a few relatively small strategical contributions. Now, If parties involved think that the answer from alternative developers to develop for the Q40 will be NO before they even ask, I think they should think about the reasons, starting from themselves. In any case, ALL of this is something that can really be done privately and off this list. Nasta
Re: [ql-users] Memory Card Types
On 13/06/02 at 18:56 Derek Stewart wrote: Hi, I habe been looking at the type os Compact flash cards, a firm near where I live sells three type : Smartmedia Compact Flask Multi Media Which is the best for the Compact flash readers. Not the right question: compact flash means compact flash. Smart Media and Multi Media cards are NOT Compact Flash, they completely different electrically and physically, and of course do not fit a CF adapter. Of course, you also missed the fourth 'major' standard, which is Memory Stick. Nasta
