Faster/wider CPU...

Nagging hardware related question? Post here!
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Faster/wider CPU...

Post by Dave »

I was looking at the 16MHz variant of that dame IC, and I have a source here in the US at $4/part, QFP. The nice thing about it is it avoids ALL the compatibility issues.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Faster/wider CPU...

Post by tofro »

and, probably the most important:

It can be made to live with an 8 bit data bus.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Faster/wider CPU...

Post by tofro »

Brane2 wrote:Why is that important ?
Ehhm, maybe because the original poster asked for it?


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Faster/wider CPU...

Post by Dave »

Can we have a developer's area where only *registered developers* can have conversations in peace? :)


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster/wider CPU...

Post by Peter »

Hi folks,

what a long thread about new hardware... maybe I should make a few comments.

I'm aware of Natami. I contacted them in the hope their FPGA core was more correct than the one I use. Their answer sounded vague and not too optimistic. Moreover, their core is not available for others. My attempts to have a look at it failed. So unless one wants pure Amiga, I see not a big chance there.

My FPGA system can execute C compiled 68k code or Atari/Amiga code for half a decade. No problem on that level. But hand-optimized QL assembler code, especially Minerva, is a much harder challenge. While it is true that I lost many years for the operating system/driver issues, I have at least rudimentary versions of Minerva and QDOS Classic by now. The problem _today_ is a CPU problem again, which is extremely difficult to debug. And lack of time.

SMSQ/E is useless as basis for new major hardware. This was done by installing a new license more than a decade ago. Ever since then, not a single QL-style mainboard etc. made it.

It is beyond me, why Rich promotes SMSQ/E as "surely the preferable way to go". Of ocurse it is not, and I'll try to explain again for this forum. I wasted years on attempting a free QL OS as a basis for new hardware, instead of dealing with the technical core challenges. It would be nice if at least a few persons understand the tragedy.

1. The socalled SMSQ/E registrar can always reject code contributions. Not much of a problem for small, low-risk contributions. Or for folks who have the right personal "connections". But who shall work on large amounts of code, on which hardware investments depend, while he has absolutely no guarantee his work will ever make it into the binary ???

2. SMSQ/E reserves the right to go closed source again. And some parts are closed. One can hope it will never happen, but pure hope is not a good basis to invest money into mainboard development. The risk seems small nowadays, simply because SMSQ/E has become unimportant, but it is still there.

3. It takes an indefinite amount of time until the "registrar" decides to include code. Shall the hardware guy risk to wait years before even small bugfixes can be passed to the user? Not be able to sell mainboards during all that time? How about the financial side? And the fact that hardware quickly becomes outdated? How about users who have bought hardware and have problems during those years of waiting for Mr. registrar?

4. SMSQ/E has been made incompatible to many open source licenses, not only the GPL. So if your code is covered by one of them, it is illegal to link with SMSQ/E. Re-invent the wheel for hardware support, just to satisfy a ridiculous license?

5. Oh yes, one could theoretically distribute changes to SMSQ/E as binary patches and every individual user would have to build his OS himself! How practical is that? What if the SMSQ/E binary is updated? Version maintainance? How will the hardware run, if the boot process already requires patches, which the user can not apply because he can not boot? How about the extra difficulty to create code in a "patchable way" instead of inserting/modifying at the place where the code belongs? Waste days for that? Weeks? Waste more time on every update of the OS? If it was practical, why did nobody ever do it?

All the best
Peter


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Faster/wider CPU...

Post by Dave »

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.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster/wider CPU...

Post by Peter »

Hi Brane,

it's not a good idea to announce new hardware in public before it is likely that a product will result. An announcements create hopes, and not being able to fulfil them, is worse than no hopes at all. Once I made the mistake to leak that I work on something FPGA based, but please don't push for more details.

As for the operating system(s) I use, they are open source and free of course. As for schematics and PCB data, they are unlikely to be pubished, at least before the one who builds/sells the boards had return on investment. For hardware, publishing these sources, does not make the boards "available". The effect goes more toward making them "unavailable" for everyone but hardware tinkerers. The one who wants to build them, could not invest in full quantities because someone else might reproduce the boards, too. This makes the boards more expensive, inefficient to handle production, and less likely someone wants to invest in series production at all.

The system would not be optimized for speed, mostly because the chips have aged during the time I lost with the OS/driver issues. It will be more important to have something working at all. If the system gets finished and well accepted, nothing forbids new boards using a faster FPGA a few years later.

The problem we work on, is triggered by Minerva, but a problem within the chip. Nobody can blame Minerva for that. Maybe it is even a problem with the FPGA synthesis tools. QDOS Classic works better but still not correct. It would be lengthy to explain, why debugging the faulty CPU is so difficult under the given circumstances. Sorry, but I won't, unless you are a hardware _and_ FPGA _and_ assembler specialist who has too much time and is eager to debug this himself :-)

All the best
Peter


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Faster/wider CPU...

Post by Dave »

Peter wrote: The system would not be optimized for speed, mostly because the chips have aged during the time I lost with the OS/driver issues. It will be more important to have something working at all. If the system gets finished and well accepted, nothing forbids new boards using a faster FPGA a few years later.
This is my view, also. It is also why I am taking the low-hanging fruit of working with existing components - the cost, time and investment needed is substantially smaller than Peter's effort. It also eliminates a lot of the problems Peter has. It's hardly an ideal end result, but it is something.

That said, I look forward to buying Peters board some day :)


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster/wider CPU...

Post by Peter »

Dave wrote: This is my view, also. It is also why I am taking the low-hanging fruit of working with existing components - the cost, time and investment needed is substantially smaller than Peter's effort. It also eliminates a lot of the problems Peter has. It's hardly an ideal end result, but it is something.
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.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Faster/wider CPU...

Post by Peter »

Brane2 wrote: Just out of curiosity, which brand are you using ?
Hehe... nice try ;-)
Brane2 wrote: If its XIlinx, haven't they hyped ability to debug internals through virtual signal analyzer ? I think it is called Chipscope...
Thanks I'm aware of this kind of tools ;) The only method guaranteed to locate the problem would be a cycle-by-cycle comparison to a correct CPU executing Minerva in exactly the same context. It would have to be so exact that even hardware interrupts occur at the very same cycle. The effort to build such a system would take too much of my time though.


Post Reply