SGC successor brainstorming

Nagging hardware related question? Post here!
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: SGC successor brainstorming

Post by Peter »

Nasta wrote:
Peter wrote:
Nasta wrote: Taking into account what kind of realistic DRAM cycles can be generated from a 48MHz clock (and I did not go into a deep analysis), we can calculate that we can squeeze 133333 access cycles into one 60Hz refresh period. This would be the theoretical maximum bandwidth only for the 68020. Since we need 32 such access cycles per display line and there are 768 display lines within one 60Hz refresh period, this means we need to take 24576 cycles for video generation. A quick division gives us an 18.43% bandwidth taken for video. The need to express all timings in terms of 48M clock cycles imposes quite penalty compared to a quick theoretical calculation.
The turning point is "such access cycles" of 125 ns for just one video read. While I'd assume two video reads in 166ns worst case. With the -60 speedgrade you mentioned, I still see two video reads in 125 ns (RASL low, keep, CASL low, CASL high, CASL low, RASL+CASL high, in 20.8ns steps). PLD timings for DRAM are much easier than taking 68020 and PLD into account. I might have overlooked a DRAM detail of course - just did a 3 minutes check.
60ns DRAM is just at the limit for not being able to use a single cycle CAS low, CAS high, so two cycles have to be used - and in fact taking into account the setup and hold parameters it becomes even more justified.
I was refering to a double video read by the PLD only and I still think it can be done in 166ns at the given clock, or 125 ns for -60. Note that the replacement PLD is much faster! ;)

Peter


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

Re: SGC successor brainstorming

Post by Peter »

Back to your older post:
Nasta wrote:What I was aiming at is a fairly small capacity (in today's terms, but probably big in QL terms) flash to boot from - which unlike the SD card (which is really very closely related technology) is soldered on the board (and can be updated from SD!) , holds something like any default code needed, even a default OS, and because the actual part is completely under control of the person who assembles the boards, is not prone to problems due to odd manufacturer's SD cards quirks etc.
What I tried to say: There are cheap variants of SD card that you can solder also - you don't need serial flash for that. In case of the Q68, the loaded "ROM" is booted by a true hardware reset after it is in memory, so I don't see what to win by serial flash. (Of course, the loader screen output could be removed just in case someone wants to load his own loader first.) Using SD card saves pins in case of double usage for removable storage.
Nasta wrote:TBH I would leave microdrive access to classic QLs.
We already have a non-classic version, which is the Q68. A SGC replacement would be especially for the original QL case... hard to estimate how many of those users would like to keep a microdrive. My guess is 30..40% including myself. What would you guess?
Nasta wrote:So, if I can make a wish, it would be for a multiplexed (reduced pin count) real 16-bit expansion bus - based on the existing pin count for the non-multiplexed version. Even if not all of the 16 bits available during the 'address phase' on the bus are not used as an address, it would open up a lot of possibility for future expansion.
I consider that. The existing bus lacks one pin for the "address latch enable", if the non-multiplexed 8 bit mode is also kept. So I need to work out a specialty. For example using chip select as an inverted address latch enable.
Nasta wrote:I also suppose that the FPGA being flash based, you essentially hard coded the boot loader code?
Yes, but it can be replaced without recompiling the whole logic.

Peter


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

Re: SGC successor brainstorming

Post by Peter »

Andrew wrote:The QL keyboard can be used with Q68 by using a matrix to PS2/USB adaptor like this https://www.nxp.com/files-static/microc ... DRM014.pdf
Thank you, but unfortunately it is not ready for a QL matrix. Someone would have to develop new software for that specific microcontroller first.
If a microcontroller is used anyway, it makes more sense to pick the one that Tobias has found. Matrix keyboard adaptor remains an open issue. :(

Peter


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: SGC successor brainstorming

Post by martyn_hill »

Hi everyone

If we do go for a uC to attach such things as a keyboard matrix, I'd be happy to develop the uC code.

We could go with an I2C connection or else map some SRAM - perhaps dualported - and develop a protocol between the mainboard and the uC (I've been thinking about this for a while) to connect the two.


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: SGC successor brainstorming

Post by Nasta »

Peter wrote:
Nasta wrote:
Peter wrote:
The turning point is "such access cycles" of 125 ns for just one video read. While I'd assume two video reads in 166ns worst case. With the -60 speedgrade you mentioned, I still see two video reads in 125 ns (RASL low, keep, CASL low, CASL high, CASL low, RASL+CASL high, in 20.8ns steps). PLD timings for DRAM are much easier than taking 68020 and PLD into account. I might have overlooked a DRAM detail of course - just did a 3 minutes check.
60ns DRAM is just at the limit for not being able to use a single cycle CAS low, CAS high, so two cycles have to be used - and in fact taking into account the setup and hold parameters it becomes even more justified.
I was refering to a double video read by the PLD only and I still think it can be done in 166ns at the given clock, or 125 ns for -60. Note that the replacement PLD is much faster! ;)

Peter
The PLD is not the problem, the RAM is, minimum CAS low and CAS high in a page mode cycle is 25ns for -60 speed grade RAM as used on the SGC (1Mx4), and, granted, it may well be that different manufacturers specify 20ns for that speed grade, but this is what I used.
In that case you can't use 1 cycle at 48MHz because that is too short at 20.8ns approximately. Then you must use the next whole clock number, 2, which is 41.6ns approx, so it comes out as minimum 9 clocks. Since a CPU cycle will follow, it becomes 10 effectively because the CPU works clock modulo 2 so a 1 clock (=1/2 CPU clock) wait would be generated anyway. At 3 consecutive reads we do get a usable advantage, 14 clocks = 3 reads in page mode rather than 12 clocks = 2 reads in regular random mode, but 3 is not a nice number in power-of-two-world :) and 16 clocks would give us 4 reads, but here we already need 128 macrocells (~2.5 INGOTs) just to buffer 4 long words (though, we could get a lot more graphics out of that).

Intuitively your calculation is perfectly sound, the problem is that this is a rather unfortunate limit case :( - It would actually be exactly as you say but at a 20MHz clock (6 clock cycles).


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: SGC successor brainstorming

Post by Nasta »

Peter wrote:Back to your older post:
What I tried to say: There are cheap variants of SD card that you can solder also - you don't need serial flash for that. In case of the Q68, the loaded "ROM" is booted by a true hardware reset after it is in memory, so I don't see what to win by serial flash. (Of course, the loader screen output could be removed just in case someone wants to load his own loader first.) Using SD card saves pins in case of double usage for removable storage.
Ah - well, I was thinking about it in terms of a more general purpose CPU, not necessarily a QL thing. Reason I mentioned it was because QSPI is VERY similar to SD so implementation would be similar and in case SD was provided too, probably pins would be shared too. QSPI is indeed I think a development of uSD, it is even simpler to use, but for our purposes if one can reliably solder in a SD card as a 'fixed storage' that can be re-programmed, of course there would not be any sense in having it if there are already all the necessary SD hardware and software resources.
Nasta wrote:TBH I would leave microdrive access to classic QLs.
We already have a non-classic version, which is the Q68. A SGC replacement would be especially for the original QL case... hard to estimate how many of those users would like to keep a microdrive. My guess is 30..40% including myself. What would you guess?
Probably less, since it's predecessors already had floppy interfaces and were around for... well, decades (almost can't believe it's been that long!).
Even then I think it became a sort of unspoken concensus that MDV contents should be transferred to other more reliable media.
However, I may be writing based on a wrong assumption - that is, the replacement replaces the whole motherboard.
If the SGC replacement indeed is a functional replacement plus graphics, then it would plug into a J1 connector on a QL motherboard, which means even if 8301 video is not used, 8302 and IPC are still available? Maybe I was confused by the mention of matrix keyboard hardware - would it not be included in this case, via IPC? And microdrives would of course be available through the 8302.
Nasta wrote:So, if I can make a wish, it would be for a multiplexed (reduced pin count) real 16-bit expansion bus - based on the existing pin count for the non-multiplexed version. Even if not all of the 16 bits available during the 'address phase' on the bus are not used as an address, it would open up a lot of possibility for future expansion.
I consider that. The existing bus lacks one pin for the "address latch enable", if the non-multiplexed 8 bit mode is also kept. So I need to work out a specialty. For example using chip select as an inverted address latch enable.
Hmmm, now again I am confused - are we talking about the Q68 or a hypothetical SGC replacement, based on Q68 technology?

If Q68, is there any actual hardware that uses the expansion port on it, or in a stage of design and manufacture that it is too late too change the bus spec and implementation (assumption here is that the FPGA could be reprogrammed on existing Q68 so the expansion port becomes multiplexed 16 bit)?
8-bit access so far (as far as I understand) was actually half-word access so no need to re-implement that, 8-bit data would still go to half of a 16-bit word. This is the case I was making a wish for, I wish I had known of how it was specified before the documentation became available, I would have started a campaign for a multiplexed 16 bit bus early :)

If SGC successor, then real 8-bit access (real address A0) has to be implemented or existing code to access 8302/IPC will not function, OR, 'half-word' access can be used but then code has to be modified to reflect the fact that previously successive byte addresses now appear as 'stretched out' to only even bytes. Re-mapping the Q68 IO area (assuming the Q68 design is used as a template for the SGC successor) to Q68 Io area is a minor issue, easily solved.

Or am I missing something?
At this point I guess I need to ask for more detail on the hardware that is being proposed for the Q68 based SGC successor?


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

Re: SGC successor brainstorming

Post by Peter »

Nasta wrote:The PLD is not the problem, the RAM is, minimum CAS low and CAS high in a page mode cycle is 25ns for -60 speed grade RAM as used on the SGC (1Mx4), and, granted, it may well be that different manufacturers specify 20ns for that speed grade, but this is what I used.
We were talking a PLD replacement in Tetroid's project, so I was looking at the MSM514400D/DL that he has in his GoldCard schematics.
See attached. It is even less that 20ns, the CAS cycle time a perfect 40 ns.

A 6 cycle access for two video reads, fitting into the CPU raster. I have not yet checked details of adjacent 68020 related timings, but it seems okay.

For all who rightfully did not follow the hardware details: This means that a VGA video output on the Tetroid SGC could be done by only replacing the EP1810 PLD and adding a few resistors. The data bus needs routing to the PLD, but the whole other circuitry and all the timings could remain as they are.

Peter
Attachments
MSM514400D.pdf
(499.85 KiB) Downloaded 104 times


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: SGC successor brainstorming

Post by Nasta »

Peter wrote:
Nasta wrote:The PLD is not the problem, the RAM is, minimum CAS low and CAS high in a page mode cycle is 25ns for -60 speed grade RAM as used on the SGC (1Mx4), and, granted, it may well be that different manufacturers specify 20ns for that speed grade, but this is what I used.
We were talking a PLD replacement in Tetroid's project, so I was looking at the MSM514400D/DL that he has in his GoldCard schematics.
See attached. It is even less that 20ns, the CAS cycle time a perfect 40 ns.

A 6 cycle access for two video reads, fitting into the CPU raster. I have not yet checked details of adjacent 68020 related timings, but it seems okay.

For all who rightfully did not follow the hardware details: This means that a VGA video output on the Tetroid SGC could be done by only replacing the EP1810 PLD and adding a few resistors. The data bus needs routing to the PLD, but the whole other circuitry and all the timings could remain as they are.

Peter
Well, that explains the confusion. That being said, a deeper analysis on access time from RAS and CAS would be in order, but I see what you mean. Strange, I looked up Toshiba parts and found a 50ns page mode for 60ns access parts, but then they did not have 50ns access parts, while OKI does.

In any case, if such a project was done, one would surely take the opportunity to use 4Mx4 DRAM chips, and getting a 32-bit wide data bus with those would produce a 16Mbyte RAM array, which would be very welcome (but also requires changing other logic and memory map). 4Mx4 in general would likely be compatible with this faster timing. Implementing a dual read would still be less overhead than the 1 CPU wait state present on the actual SGC and would make it possible to get 1024x768 in MODE4. The one remaining thing would be figuring out if LCD compatible VESA timings can be had based on a 48MHz clock (trying to keep the PLD logic simple). I am also guessing old QL monitor compatibility is NOT supported (I for one will not shed a tear for that...).
Twice the above overhead gets us into Aurora territory, and it would still be less than the 1 waitstate on current SGC.

There are some other things to consider, such as slow QL bus timing may require more cycles to complete than the CPU will have at it's disposal, between two two RAM accesses to get screen data, and this gets messy depending on what revision of the QL motherboard is in use. The reason for this is the 8301, while possibly not used for video, will impose slow timing on 8302 access. If contention arises with screen data reads, it may complicate some of the software managed timing for IPC and MDV. However, a larger CPLD may cope with that by implementing a data buffer of some kind, since, unlike present EP1810, it would need data bus pins anyway for screen data access. Another (obvious?) solution would be to re-do the whole motherboard either by making a full replacement or something that fits this new 'SGC+', which was the idea behind Aurora (sans MDV).


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

Re: SGC successor brainstorming

Post by Peter »

Nasta wrote:There are some other things to consider, such as slow QL bus timing may require more cycles to complete than the CPU will have at it's disposal, between two two RAM accesses to get screen data, and this gets messy depending on what revision of the QL motherboard is in use.
Yes, I assumed that video DRAM read could always wait for worstcase CPU bus cycle to complete, by adding enough pixels output buffer. Memory consumption of MODE4 is so low that I still guess the proposed PLD is sufficient for that.

This would be the way I go, if I had the SGC already in my CAD and was working toward a replacement PLD anyway. But I am not - it depends on Tetroid's plans which we don't know. Something that close to the original SGC has it's charm for the original case. I find a Motorola chip and working microdrives an emotional value. One could also see it as a late tribute to Stuart Honeyball - bringing a video unit which he wanted, but never completed, into his finest design.

To be honest, inside the original QL case, I prefer such a solution over the much more modern design that I would do myself.

Peter


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

Re: SGC successor brainstorming

Post by Peter »

Nasta wrote:Even then I think it became a sort of unspoken concensus that MDV contents should be transferred to other more reliable media. However, I may be writing based on a wrong assumption - that is, the replacement replaces the whole motherboard.
To transfer cartridges, you need a machine that still supports them. Even if that's rarely needed, some emotional value of keeping the microdirves remains. After all, this discussion is only about something for the original QL case - pure nostalgia.

When I started this topic, I had a plugin in mind which keeps the original mainboard. The proposal to replace the whole mainboard came in later. I'm not always sure which post refers to which option. ;)
Nasta wrote:Maybe I was confused by the mention of matrix keyboard hardware - would it not be included in this case, via IPC? And microdrives would of course be available through the 8302.
Mention of matrix keyboard was not related to SGC replacement. That would indeed be a Q68 inside a QL case. By the way, a Q68 with matrix keyboard adaptor could do both: Replace the QL mainboard, sacrificing the microdrives, or sit beside the QL mainboard and access the microdrives via QL network.

Regarding 16 Bit multiplexed extension bus:
Nasta wrote:Hmmm, now again I am confused - are we talking about the Q68 or a hypothetical SGC replacement, based on Q68 technology?
That was unclear, but in both cases there was request to provide the Q68 extension bus as it is. So a multiplexed mode could only come in a way that does not take away the parallel mode.
Nasta wrote:If Q68, is there any actual hardware that uses the expansion port on it, or in a stage of design and manufacture that it is too late too change the bus spec and implementation (assumption here is that the FPGA could be reprogrammed on existing Q68 so the expansion port becomes multiplexed 16 bit)?
There is not yet finished hardware for the Q68 expansion port, but I heard from two persons who seem to be tinkering with it. Maybe private circiutry which will never be distributed.

I think a 16 bit multiplexed access mode could be provided as an optional update (maybe together with cache and other goodies) but only as a backward compatible add-on. It requires a larger and therefore different adress space anyway.
Nasta wrote:This is the case I was making a wish for, I wish I had known of how it was specified before the documentation became available, I would have started a campaign for a multiplexed 16 bit bus early :)
Not sure I'd have spent the time back then, even if you had intervened. I had little reason to expect actual usage of the extension bus. There was a huge workload to make the Q68 available at all. At some parts I had to compromise, so this bus was just provided as a simple "better than nothing" under extreme pin shortage. (The only place where to steal an adress latch enable signal would have been the second SD card, which has the luxury of a completely separate SPI interface. But there were good reasons for that also, back then.)

We decided to not even solder a connector by default. As long as only the QLNET signal is used, it's easier to solder directly to the board.
Nasta wrote:Or am I missing something?
I don't think so. However the main purpose of this topic for me remain these two questions:

Is a SGC successor for the original QL case still important to keep the QL scene alive?
Or do the Tetroid (S)GC clones and the Q68 already cover most needs?

Peter


Post Reply