RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » Superfast Multicomp implementation!!
Re: Superfast Multicomp implementation? [message #5779 is a reply to message #5778] Wed, 19 December 2018 06:21 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
It seems to me that you should run the timing specific components (terminal, baudrate uart etc) from the input signal (50 MHZ) of the PLL, not from the output
Re: Superfast Multicomp implementation? [message #5781 is a reply to message #5779] Wed, 19 December 2018 06:55 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Hi Rienk

Yes, that is what I do. Only the CPU and SD card clocks come off the PLL - TERMINAL and baud rate divider both use the 50Hz clock (I haven't incorporated a BRG yet).

I was wondering if TERMINAL could be run faster, but I expect it uses clk for the timing of the video signal and will break in short order if I change it to use the PLL.

I edited my previous post to say that I'd restored it now.

Thanks
JonB

[Updated on: Wed, 19 December 2018 06:56]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5783 is a reply to message #5781] Wed, 19 December 2018 07:56 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Now I am experimenting a bit more, with the more basic configuration (4k internal RAM, BASIC interpreter, PLL, Z80, UART). It seems to be happy to run at 95Mhz. At 100Mhz it will boot into the BASIC interpreter, but locks up as you enter the first line of code. My plan is to build it up incrementally in order to see where the bottle necks are.

Let's swap out the internal RAM for the external fast RAM module:
95Mhz - works.
100Mhz - works.
110Mhz - works.
120Mhz - works.
125Mhz - works.

At this point I am beginning to get a bit Shocked

130Mhz + fast RAM - tries to boot but fails. Maybe it is working, but the CPU is too fast for the serial port? Let's try going from 115200 baud to 230400... to do this I set the baud rate setting line in Microcomputer.vhd to "serialClkCount <= serialClkCount + 4832;". Amazingly, it actually works at this speed, with the 125Mhz CPU clock, but it will not run at 130Mhz so baud rate's not the issue.

Just for fun, though, I've upped the baud rate to 460800 and it still works (even faster on screen updates). The next step was 921600 baud with a clock increment of 19,328 and while it did boot to BASIC it didn't quite work when I flooded it with data (as in: 10 FOR X+1 TO 10000: PRINT X;: NEXT X).

So, I have a maximum CPU speed with external RAM of 125Mhz and a 460800 baud serial port. I know that the moment I build in the SD card or VGA TERMINAL it will fail.. maybe I can introduce CPU wait states or something like that?

[Updated on: Wed, 19 December 2018 08:54]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5784 is a reply to message #5783] Thu, 20 December 2018 02:09 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
I've integrated Neal's SDCARD component (the one updated for SDHC) and reran the STevie compilation test. It completed in 2:01 with 50/50 Mhz clock speeds, which surprised me. I've reverted back to standard for now.
Re: Superfast Multicomp implementation? [message #5785 is a reply to message #5784] Thu, 20 December 2018 02:35 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
Neals SDCARD component is very conservative. It normally runs with a 500 kHz serial clock. My version (attached) initializes as 250 kHz but runs at 25 MHz otherwise.

The SD card specification states that the initialization clock speed should not exceed 400 kHz. This is to accommodate some very slow early cards.
My version switches to full speed after init. full speed, being half of the master clock (in my case 25 MHz)

[Updated on: Sun, 23 December 2018 01:51]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5786 is a reply to message #5785] Thu, 20 December 2018 04:20 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Thanks, Rienk - there will be a short delay while I fix a corrupted A: drive on my SD card... Not sure what happened but I suspect running Neal's SDCARD component at 50Mhz may have contributed to it..
Re: Superfast Multicomp implementation? [message #5787 is a reply to message #5786] Thu, 20 December 2018 05:30 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
The price of progress...
Re: Superfast Multicomp implementation? [message #5788 is a reply to message #5787] Thu, 20 December 2018 07:40 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
OK then, how about this (attached)? It's another SanSerif type font, but thinner than the PCW one. I think it needs to be less tall as well..

(Edit: Fixed the position of the full stop in the hex file attachment)

[Updated on: Thu, 20 December 2018 08:31]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5789 is a reply to message #5788] Thu, 20 December 2018 08:10 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Or.. with a small mod to the VGA parameters in the SBCTextDisplayRGB.vhd file we can have a proper square pixel (at the moment they are twice as high as they are wide).

constant VERT_PIXEL_SCANLINES : integer := 1;

instead of

constant VERT_PIXEL_SCANLINES : integer := 2;


The thin font looks a bit better like this, but the lines shown on the screen are all you get (in other words, it only uses half of the panel). It may be possible to double the number of lines but I expect the DisplayRam would need to be doubled, too. You also have the problem of CP/M programs assuming 80x24.

[Updated on: Thu, 20 December 2018 08:11]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5793 is a reply to message #5789] Sun, 23 December 2018 08:42 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
I decided to venture into the high speed arena too.

I now have a Cyclone II system (my version .. see builderpages) running stable at a 120 MHz system clock. (PLL times 12 devided by 5.Wink
I only had to re-calculate the values of the baudrate generator. Every component uses the 120 MHz base clock except the SBCTextDisplayRGB.
Both CPU clock and the SDCARD SPI clk run at 60 MHz (SDCARD inits at about 450 kHz)
With some tweaks I could fit a VGA terminal plus 2xUART+BRG, MMU and SDCARD components.
two IS61LV5128AL-10 SRAMS are fitted.
ZEXDOC runs under 13 minutes
Re: Superfast Multicomp implementation? [message #5794 is a reply to message #5793] Sun, 23 December 2018 09:45 Go to previous messageGo to next message
tingo is currently offline  tingo
Messages: 76
Registered: February 2017
Location: Oslo, Norway
Member
Nice! This thread makes me want to get back to my multicomp experiments Very Happy

Torfinn
Re: Superfast Multicomp implementation? [message #5795 is a reply to message #5794] Mon, 24 December 2018 02:25 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Hi Rienk

How did you manage that? Or, perhaps I should say "What am I doing wrong?".. I assume since you ran ZEXDOC that you have CP/M up?

Cheers
JonB
Re: Superfast Multicomp implementation? [message #5796 is a reply to message #5795] Mon, 24 December 2018 04:37 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
Not too much to it.
I used my base setup from my builder pages.
I added the PLL, and generated new baudrate and interrupt values based on the factor 2.4
I had trouble fitting it all so I made some optimizations ( I basically accepted all changes suggested by Quartus) and modified the SDCARD module a bit.
There was no benefit in changing the VGA timings, so I left them alone running on 50 MHz.
It now fits and runs.

You will need my BIOSes for this setup. CP/M images for Dos+, CP/M 2.2, CP/M 3, MP/M 2, 'ROM' BASIC, ZSDOS and ZPM3 can be found on my builder pages
Alternatively you can exchange the ROM file for your specific configuration.

I attached the VHD files. make sure the pin assignments fit your hardware.

Success Rienk

[Updated on: Mon, 24 December 2018 04:39]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5797 is a reply to message #5796] Mon, 24 December 2018 05:52 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Thanks, Rienk! I'll check it out.

Just a minor point though. You say the clock is 120Mhz but ZEXDOC is completing in just under 13mins. My 50Mhz setup completes in 15.5 minutes. I'd expect you to be getting 6 mins or less... am I missing something? Smile

Anyway, happy Christmas!
Re: Superfast Multicomp implementation? [message #5798 is a reply to message #5797] Mon, 24 December 2018 05:59 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 430
Registered: March 2017
Location: New Mexico, USA
Senior Member
ZEXDOC is CPU and memory intensive, so 120MHz Z80 should finish the test in 6.5 minutes, unless there are lots of waits for memory access.
Bill
Re: Superfast Multicomp implementation? [message #5799 is a reply to message #5797] Mon, 24 December 2018 06:03 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
The CPU clock is 60 MHz. (120/2). 5/6*15.5=12.9

I tried 125 MHz. This mostly runs, but not stable. so I stuck to 120.

Oh, and in case you want to know, I'm using a Chinese knockoff 2GB SDHC micro SD card. It says "Kingston" on it, but somehow I doubt that...

[Updated on: Mon, 24 December 2018 06:08]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5800 is a reply to message #5567] Tue, 25 December 2018 05:13 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
OK, I see. You're using a clock divider in your in your VHD, so running the PLL at 120Mhz. What I do is wire the PLL output direct to my CPU and SD card so I do not have any intermediate VHDL. I set the CPU and SD at 50Hz in the PLL Megafunction wizard. I can run at 60/40 (as documented above) and I guess that'd give me the same ZEXDOC score as you. But... the T80 core can run at a genuine 120mhz with the external RAM and UART, so I am looking to get the TERMINAL and SD card to handle it, too (not the speed necessarily, but to not crash when the CPU is that fast).
Re: Superfast Multicomp implementation? [message #5801 is a reply to message #5800] Wed, 26 December 2018 07:57 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
I don't know. Anything above 60 MHz CPU clock is either unresponsive or unstable. Sometimes it seems to work, but then zexdoc will stall somewhere in the middle.
Also with a higher clock it won't be faster. I feel maybe clock pulses get skipped. Timequest does not like it at all Sad
Re: Superfast Multicomp implementation? [message #5802 is a reply to message #5801] Thu, 27 December 2018 00:15 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Try this...

It's a minimal Multicomp with BASIC only, running the Z80 at 120Mhz and the serial line at 460800 baud. Requires fast external RAM. As I said before, it fails once TERMINAL or SDCARD components are added so it's no use for CP/M, but it does demonstrate what's possible.

Smile

If we want to take CP/M beyond 60Mhz, I think it'll be necessary to work out why TERMINAL and SDCARD don't like running with a faster CPU.
Re: Superfast Multicomp implementation? [message #5803 is a reply to message #5802] Thu, 27 December 2018 02:56 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
I suspect that with added components the logic chains gets too long. Every gate adds delay and the added delays 'overrun' the clock. The sd card and terminal component do not cause the problem, it's the combination of all the parts. So you can make a really fast simple ROM-based machine, or a slower complex one. I don't think there is a simple fix for this. We're just running into the hardware limitations.
Re: Superfast Multicomp implementation? [message #5805 is a reply to message #5802] Thu, 27 December 2018 05:10 Go to previous messageGo to next message
b1ackmai1er is currently offline  b1ackmai1er
Messages: 265
Registered: November 2017
Senior Member

Just as an idea to explore ...

Maybe you need to make the modules asynchronous so they are "speed independant".

i.e. add ready/wait signals, add input buffers.

Regards Phil.

Re: Superfast Multicomp implementation? [message #5806 is a reply to message #5805] Thu, 27 December 2018 05:23 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
You mean synchronous, surely?

Neal suggested something similar. He said that the design was asynchronous like old computers but this is not how it's done today. I don't really know how to make it synchronous, or if the additional logic will fit. I did see that the Z80 wait_n line is fixed at 1, though (ie not waiting) in the standard Microcomputer.vhd.
Re: Superfast Multicomp implementation? [message #5808 is a reply to message #5805] Thu, 27 December 2018 07:09 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 223
Registered: October 2015
Senior Member
You make them asynchronous to the CPU core.

When you write to the relevant I/O port you latch everything you need and assert wait within the CPU clock domain. When your device finishes the I/O it deasserts wait.

You can also run at a subset of the CPU clock without all the extra glue logic with a bit of care. The penalty you pay is that if you talk too fast to it then stuff breaks. That's sort of how the 1MHz floppy controllers were nailed onto 4MHZ processors and is how things like the VDP on the MSX work. Even an LDI takes 16 clocks, so your interface doesn't have to run at anything like the CPU clock to keep up with the processor.

To give you an idea of how much you don't need the clock - the Sinclair Spectrum has a clock signal on the expansion connector that is basically broken and unusable on many machines. All the expansions work just fine without needing access to the CPU clock signal.
Re: Superfast Multicomp implementation? [message #5811 is a reply to message #5808] Wed, 02 January 2019 05:38 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
Not sure.
I've been experimenting with my Cyclone IV board. I can run it up to 132 MHz (66 MHZ CPU/SPI clock) with the system remaining stable.
At 140 MHz (70 MHz CPU/SPI clock) the system will boot, run CP/M, copy files (with verify) etc, but running ZEXDOC will show errors.
ZEXDOC will produce the same behavior either running from SD card or RAM disk.
This does not feel like a peripheral interface overrun.
Perhaps the increased LE count creates too much load on certain gates to sustain the necessary slew rates. (just a guess)
Re: Superfast Multicomp implementation? [message #5820 is a reply to message #5811] Wed, 09 January 2019 04:38 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
I posted 2 configurations (for Cyclone II and IV) in my builderpages.
It took some effort to get all components to 'behave'. Finally I got it stable using two PLL outputs of the same frequency but shifted by 90 degrees. One supplies CPU/ROM/SD and the other the textterminal. Don't ask me why this works, but it seems to do the trick.
The only issue I still have is that the IV system occasionally drops an output character in the serial terminal. I'm still working on that

The Cyclone II operates at 120 MHz (60 MHz CPU frequency). The Cyclone IV at 132 MHz (or 66 MHz CPU).
noteworthy: The Cyclone IV system clock speed represents 'true' clockspeed (compared to a real Z80) while the Cyclone II operates at 83 percent of that (even when not overclocked). Thus here the IV solution is 33% faster than the II while the clock is only 10 % faster.

btw I use this mbasic80 code as a benchmark:
10 PRINT "Find prime numbers between 1-5000"
100 L=5000
110 DIM N(L)
120 INPUT "How many iterations";Q
125 SM=PEEK(67): SS=PEEK(68)
130 FOR T=1 TO Q
140 FOR I=1 TO L
150 N(I)=1
160 NEXT I
170 P=2
180 FOR I=P+P TO L STEP P
190 N(I)=0
200 NEXT I
210 P=P+1
220 IF P=L THEN 240
230 IF N(P) <> 0 THEN 180 ELSE 210
240 NEXT T
250 EM=PEEK(67): ES=PEEK(68)
260 S=(INT(SM/16)*10 + SM MOD 16)*60 +(INT(SS/16)*10 + SS MOD 16)
270 E=(INT(EM/16)*10 + EM MOD 16)*60 +(INT(ES/16)*10 + ES MOD 16)
280 S=E-S
290 IF S<1 THEN S=S+3600
300 PRINT S;" seconds"
305 P=0
310 FOR I=1 TO L
320 IF N(I)>0 THEN P=P+1
330 NEXT I
340 PRINT P;" primes"


0x4C,0x4D stores minutes and seconds in BCD in my system.
10 iterations for system II produces 83 seconds, for system IV 56.

[Updated on: Wed, 09 January 2019 04:42]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5821 is a reply to message #5820] Wed, 09 January 2019 06:08 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 223
Registered: October 2015
Senior Member
Did you run all the validation tests and did it find any propogation timing errors, or other warnings about power or fan out ? In theory the tool chain should tell you if you are violating a timing constraint.

If you've got clock propogation or other timing problems then clocking bits of the board the way you are will sometimes fix it (and indeed is a real world thing where you delay the clock to match the propogation time of the related signals). If you have bidirectional signalling however just delaying the clock usually introduces new problems. There are "proper" text book ways to do this with latches between the time domains or with an asynchronous FIFO each way. There are also pulse stretching techniques that are hairier but use less resources.

Once you have a FIFO you can clock the terminal entirely independently (eg far slower) than the system proper.

Alan
Re: Superfast Multicomp implementation? [message #5822 is a reply to message #5821] Wed, 09 January 2019 07:05 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
Currently I am just winging it. I wasn't planning on redesigning the whole system yet. There are still many things I don't really understand but I must say it is a whole lot of fun to have for just a few bucks.
Re: Superfast Multicomp implementation? [message #5823 is a reply to message #5822] Wed, 09 January 2019 09:39 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Amen to that. Love the response of the thing, so quick. I'm almost reluctant to go back to using real hardware now!

But, latest project: https://stardot.org.uk/forums/viewtopic.php?f=45&t=16316

..I can't help myself!
Re: Superfast Multicomp implementation? [message #5900 is a reply to message #5823] Thu, 31 January 2019 04:27 Go to previous message
bingo600 is currently offline  bingo600
Messages: 14
Registered: September 2016
Location: Denmark
Junior Member
Well done guyzz - Seems to be some speedy Z80's there.

In order to "shut up Quartus warnings" , i used some timing constraints , that "might" have improved the routing.
If you want to try it out , uncomment the one needed.

Or you might already have done this .. I'm no VHDL (or Quartus/ISE) expert , gust used google.

#**************************************************************
# Create Clock
#**************************************************************

# 50MHz Osc in 
create_clock -name {pll_clk} -period 20.000 -waveform { 0.000 10.000 } [get_ports {pll_clk}]

# 50MHz Pll clock ut
#create_clock -name {clk} -period 20.000 -waveform { 0.000 10.000 } 

# 75MHz Pll clock out 
#create_clock -name {clk} -period 13.333 -waveform { 0.000 6.667 } 

# 80MHz Pll clock out 
#create_clock -name {clk} -period 12.500 -waveform { 0.000 6.250 } 

# 90MHz Pll clock out 
create_clock -name {clk} -period 11.111 -waveform { 0.000 5.556 } 

# 100MHz Pll clock out 
#create_clock -name {clk} -period 10.000 -waveform { 0.000 5.000 } 

# Haven't really got any idea about what this means , but it "shuts up quartus"
derive_pll_clocks



/Bingo


I prefer linux
Previous Topic: Chipset based IBM PC/XT compatible 8088 board
Next Topic: 8080 varieties - differences


Current Time: Mon Dec 09 04:44:48 PST 2019

Total time taken to generate the page: 0.01483 seconds