Q68 Order Process

Nagging hardware related question? Post here!
BackToQL
ROM Dongle
Posts: 22
Joined: Tue Sep 22, 2020 3:59 pm

Re: Q68 Order Process

Post by BackToQL »

Derek_Stewart wrote: Maybe a small deposit, say 25% of tge total price, but I will consider this option over Christmas and get back to you.
I'd be happy to pay a 25% deposit.

Regards,
Peter.


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: Q68 Order Process

Post by dilwyn »

BackToQL wrote:
Derek_Stewart wrote: Maybe a small deposit, say 25% of tge total price, but I will consider this option over Christmas and get back to you.
I'd be happy to pay a 25% deposit.

Regards,
Peter.
I'd be happy with this too, Derek.


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

Re: Q68 Order Process

Post by Peter »

Derek, I would recommend to check parts availability first. About one year lead time for semiconductors has become normal in this crisis.


IKH
ROM Dongle
Posts: 10
Joined: Tue Sep 08, 2020 7:22 am
Location: Germany

Re: Q68 Order Process

Post by IKH »

Derek, I would also be happy with paying a deposit. :P
Ian.


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Q68 Order Process

Post by Derek_Stewart »

Hi,

Thank you for the kind support in the production of the Q68, I will consider the options and get back to you all with a possible solution.

With regards to the long lead times on parts, I am looking into this and I will report back if there is a issues with part deliveries.


Regards,

Derek
TheManticore
ROM Dongle
Posts: 2
Joined: Fri May 21, 2021 1:43 am

Re: Q68 Order Process

Post by TheManticore »

From the other side of the pond.. +1 on a deposit.
Additionally, I was curious about how networking is implemented on the Q68, Is it integrated with the PCB, and simply a matter of fitting the additional components while you are assembling them? (I ask as I believe I had asked for the Q68 board only, as I intended to install it in a custom enclosure).

Also, based on some previous posts, it sounds like you chose not to integrate an FPU on the Q68, is that correct?

Should you choose to evolve the design into something more *nix friendly, please consider implementing both an FPU and an MMU (especially if integrating additional RAM).

Thank you so much for keeping us all in the loop, we all appreciate your efforts.

:D

e


Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: Q68 Order Process

Post by Tinyfpga »

I understood that one of the "positive features" of SMS was that it does not require an MMU. I imagine that implementing an MMU in low cost FPGA's is far from a trivial task. Would it not be better to buy a Raspberry pi to play with --nixs? They are also cheaper.

Something that would be interesting, is support, both in hardware and in software, for i2C, including i2c to rs485 for long distance communication.
Perhaps a Q68 bus to rs485 interface together with system support would be more useful, and probably easier, than an MMU.

The ability to control and measure external devices would, in my opinion, greatly enhance the Q68.


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

Re: Q68 Order Process

Post by tofro »

Tinyfpga wrote:I understood that one of the "positive features" of SMS was that it does not require an MMU. I imagine that implementing an MMU in low cost FPGA's is far from a trivial task. Would it not be better to buy a Raspberry pi to play with --nixs? They are also cheaper.
Agree with that - Q68 is targetted to be an SMSQ/E machine, no more, no less. There are a lot of other more "generally usable" SBCs out there that are much cheaper options.
Tinyfpga wrote: Something that would be interesting, is support, both in hardware and in software, for i2C, including i2c to rs485 for long distance communication.
Perhaps a Q68 bus to rs485 interface together with system support would be more useful, and probably easier, than an MMU.

The ability to control and measure external devices would, in my opinion, greatly enhance the Q68.
Well, what exactly do you miss? I2C is there and usable, same for serial and Ethernet, and if you have further needs to adapt external hardware, there's always the expansion bus. I agree some usable, simple examples would be useful, but building that would require someone with a personal interest in such things.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Tinyfpga
Gold Card
Posts: 252
Joined: Thu Sep 27, 2018 1:59 am

Re: Q68 Order Process

Post by Tinyfpga »

I have no idea how to use the i2C bus. As far as I know there is no driver for it and no way of using it in BASIC. I guess, as it stands, one would have to write communication code in assembly. This is beyond me. i2C was a short distance bus (1Meter at 100k bits/sec) and needs additional electronics if one wants to drive higher voltage devices and if one wants to supply power as well as information. (ie. power over communication cable)

The same applies with the expansion bus. I have no idea how to use it from BASIC, without using PEEKS and POKES, and I don't know enough to do this.

I am someone with a personal interest in expanding the I/0 capability of the Q68 but don't have the technical skills to do so. What I could do is manufacture PCB adaptors and publish instruction manuals for general distribution, if someone were to provide me with circuit diagrams. Drivers could be created once the hardware existed, a bit like an Ethernet driver was written after the Q68 was manufactured.

Adafruit, for example, sell i2C, pressure, temperature, humidity rotary encoder, digital potentiometer devices etc. etc, that would be fun to use if only I knew how.
Last edited by Tinyfpga on Sun Jan 09, 2022 5:34 pm, edited 1 time in total.


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Q68 Order Process

Post by Derek_Stewart »

TheManticore wrote:From the other side of the pond.. +1 on a deposit.
Additionally, I was curious about how networking is implemented on the Q68, Is it integrated with the PCB, and simply a matter of fitting the additional components while you are assembling them? (I ask as I believe I had asked for the Q68 board only, as I intended to install it in a custom enclosure).
The Q68 can connect to the QL Network with a simple circuit, which with QLUB can connect Q68, QL and QPC2.

The Q68 has Ethernet capabilites and connect over ethernet eith QPC2 as a network device.
TheManticore wrote:Also, based on some previous posts, it sounds like you chose not to integrate an FPU on the Q68, is that correct?
The Q68 is a 68000 based CPU system implemented in FPGA, which does not have a MMU or FPU, nether does a standard QL even with a Super Gold Card.

SMSQ/E is so well written, MMU and FPU is not required.
TheManticore wrote:Should you choose to evolve the design into something more *nix friendly, please consider implementing both an FPU and an MMU (especially if integrating additional RAM).
I personally think Linux on the QL or Q68 would not be worth the effort, if all the Linux applications were ported to the QL/Q68 then why need Linux.

SMSQ/E uses a highly efficient job schedulling system, with enhanced memory management, which if thousanfs of people used the Q68, more software would be available.

I use Linux as a Desktop machine, Linux for a Raid Server, so I am not againist Linux, quite the reverse.

The Q68 has 32Mb ram which more than enough for most QL applications.

I select 255Mb ram on QPC2, but I fo not see the benefit of the extra ram.

There are other Q68 expansion facilities, including I2C, which requies the I2C port to be Bit-Banged to address the I2C device.

All of the old TF Services I2C devices work with the Q68 and also some modern equivalents I have made...


Regards,

Derek
Post Reply