Faster/wider CPU...

[Mr_Navigator]

Oh your that Peter, let me publicly thank you for all the work you have put in to the SD card interface

[Peter]

Oh your that Peter, let me publicly thank you for all the work you have put in to the SD card interface

Your very welcome Let's hope that my SuperGoldCard related problems with QL-SD were not general, but just my second hand black box. I now bought a brandnew German QL, which I shall try after I found the time to modify the power supply. I would enjoy to own a SuperGoldCard QL where no floppy and harddisk is needed and no other stuff sticks out of the black case. Feels good to use the microdrives slots again

[dilwyn]

Hi Peter,

I really appreciate your input into this thread.

I agree with you on the SMSQ/E license situation - I think it is a very unfortunate license that was designed not to encourage development (which it hasn't) but to protect incumbent interests (which it has.)

Is it possible to contact Lau and obtain the sources or rights to Minerva? I am convinced he knows it's economically worthless now, and if he decided to extract a price for it, it could be reasonably small. Is that an option? I know most of it is freely available, but the whole thing, not quite.

The sources and Minerva 1.98 ROM images are freely downloadable from my website http://www.dilwyn.me.uk/qlrom/index.html to anyone who wants to have a look. I haven't checked the licence terms to see if it allows for modified derivatives to be used - I would presume that Peter has already looked at this. Alternatively, if it doesn't, it might be possible to supply a program which patches an existing Minerva ROM as required, perhaps. Also, I wonder if QDOS Classic author Mark Swift is still around to provide input to this?

Dilwyn

[dilwyn]

Good luck. Something finished is always better that a nice concept which becomes an endless story. I also plan for some "last resort" in case we fail to debug the FPGA CPU. There are provisions to add a hardware CPU on a daughterboard I was near to that decision already, but the partial success with QDOS Classic gave new hope. My biggest obstacle has become lack of time, and I'm therefore very glad that Adrian has taken over the QL-SD project from me. This is of great help.

The history of the QL is peppered with hardware designs which nearly failed because insufficient consideration was given to software/OS (e.g. QXL, Aurora, to some extent Q40). Which is why I am glad that Peter has given this a lot of thought and time to try to implement two versions of QDOS and chosen not to announce this board too early. I knew of it a few years back when the hardware was being designed, but chose not to say anything.

Peter - while the situation is not too promising at the moment, I nonetheless wish you every luck with this project and would like to thank you here in public for your efforts to continue making new QL hardware.

Now the next thing I wanted to find out was whether zeccie has made any progress with the Java QL system? http://www.theqlforum.com/viewtopic.php?f=8&t=170#p888

Dilwyn

[Peter]

The sources and Minerva 1.98 ROM images are freely downloadable from my website http://www.dilwyn.me.uk/qlrom/index.html to anyone who wants to have a look. I haven't checked the licence terms to see if it allows for modified derivatives to be used - I would presume that Peter has already looked at this. Alternatively, if it doesn't, it might be possible to supply a program which patches an existing Minerva ROM as required, perhaps.

Laurence Reeves has kindly released the sources for Minerva 1.98 under the GNU General Public License. He states that the license covers all supplied files, even if not individually mentioned in each file.
See http://bergbland.dyndns.info/downloads.htm

Also, I wonder if QDOS Classic author Mark Swift is still around to provide input to this?

I tried to contact Mark years ago, but received no reply. QDOS Classic is offered as a free program, but a specific license is not mentioned. Both sources and binaries can be downloaded from http://www.mswift.unisonplus.net/ql/index.html

[dilwyn]

I've checked SMSQ/E main site.

And download the source. But it seems that beside pure asm sources there is no documentation.

How is one supposed to use these sources ?

EDIT: I have just found "QDOS SMS Reference Manual.pdf" and "QPTR update document for SMSQ/E" on Marcel Kilgus site...

In addition to what Rich mentioned, visit the SQLUG site http://www.jms1.supanet.com/SQLUG/gwilt/gwilt.htm, where George Gwilt has a package explaining how to use his GWASS assembler program to compile SMSQE. On that page, scroll down to the Articles section where you'll find SMSQE Compilation with Gwass.

(Sorry for late reply, I only just remembered about it)

Dilwyn

[Dave]

Without viewing the videos or following the links, I would NOT say "why?....." or "x is better"... In fact, I think it would be great if someone who knew that stuff inside out would do it, and share it with the community so we could all feed back into it and make it real.

All the ideas and suggestions in the world are worth less than one, single, working computer that people can plug in and use. Whatever it's made from.

[Dave]

You have mad skills. Why don't you do it?

[thorsinclair]

I'm curious and interested to see what will come out of this. What will be the project? Sth like a Mega QL, improved hardware and OS?

....

[Nasta]

The EC and HC variants both do that. I can, however, obtain EC variants for less than half the cost of a similarly clocked HC.

I'm curious if there's a simple way to have a faster CPU than the 7.5MHz of the 68008, and/or if there's a simple way to have wider memory accesses, and still use the onboard facilities, like the gold cards do, but without lots of heavyweight custom logic.

I am looking at whatever comes out of this thread being an open-source design.

OK I'm quoting this from page 1, so doing a 'where have you been' here but:
In fact the least custom logic trickery is required with the 68020. That being said, a piece of code is required to set it up as a 68020, mostly to do with the interrupt stack pointer.
In any case, to get a faster and wider QL, your best bet would be a 68(EC)020.
Disregarding for the moment some members of the 68300 family (which are actually not that easy to get and quite expensive), the 68020 is the only one capable of 8 and 16 bit width accesses with minimal need for external logic (the logic needed is an expanded address decoder that tells the 68020 which addresses have what bus width). Getting a 68(EC)000 to do the same is 'a bit' more complicated as it requires logic to break every 16-bit bus cycle into two 8-bit ones when an access is attempted to addresses that use an 8-bit bus, this also includes some data bus multiplexing and latching etc.
Further, unlike other 'higher' members of the 68k family, the 68020 implements all the original 68020 instructions (notably MOVEP is missing from others). It also adds a bunch of instructions, some of which are missing from other more advanced chips.
Most of the logic associated with getting the 68020 to work 'QL style' i.e. capable of accessing the old ULA chips, revolves around slowing it down sufficiently.
In particular, the ZX8301 is the main problem here due to it's sharing the memory bus in order to generate video output. It relies on some 68008/68000 particulars regarding bus access, and also on the CPU clock being close to 7.5MHz. In theory it should be able to run completely asynchronously, but it does not (It will work with the CPU on it's own independent clock as long as this CPU clock is not too far from 7,5MHz, IIRC about 9MHz is the maximum before problems start).
The 8302 however just emulates a bunch of simple registers and it's not too finicky on timing. That being said, things like Microdrives (spit, spit, spit!!!) and network rely on some timing implemented in software so a faster CPU will upset this and they will not work (a good question would be who would need them to work...). Most of the software on the SGC revolves around patching this up. In fact, it could probably be patched up itself to run a 68020 with more RAM, for instance.

When expanding the RAM of QDOS/SMSQ machines, there is a requirement that the top 3 address lines (A29, A30, A31) remain 'don't care' as far as memory decoding is concerned. In effect, this limits the maximum size of the total usable memory area to 512M bytes. This has nothing to do with the OS, but rather with one of the SuperBasic compilers (Qliberator?) using the top 3 address bits in it's data structures, for something. The aforementioned 512M should contain all the ROM, RAM and IO, including any expansion areas.
The 68EC020 however has only 24 address lines and therefore can address only 16M of RAM, unlike the full 4G of the regular 68020. Both the regular 020 and the EC020 IIRC were available up to 33MHz and both can actually be overclocked a fair amount assuming the rata and address lines are suitable buffered.
One particular impression from long ago - the regular 68020 despite being largely NMOS actually uses less power than the original 68008, even though it was running at 25 MHz in my case
I actually made a small board that made the 68020 run with an 8-bit external bus, a bit of logic and a 7805 regulator, inspired by what I read about the Thor 20. It actually worked up to the F1/F2 display at which point it froze probably due to the interrupt stack pointer issue.