|
Re: Superfast Multicomp implementation? [message #5781 is a reply to message #5779] |
Wed, 19 December 2018 06:55 |
JonB
Messages: 92 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 |
JonB
Messages: 92 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
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 #5785 is a reply to message #5784] |
Thu, 20 December 2018 02:35 |
rhkoolstar
Messages: 276 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 #5789 is a reply to message #5788] |
Thu, 20 December 2018 08:10 |
JonB
Messages: 92 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 #5796 is a reply to message #5795] |
Mon, 24 December 2018 04:37 |
rhkoolstar
Messages: 276 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 #5820 is a reply to message #5811] |
Wed, 09 January 2019 04:38 |
rhkoolstar
Messages: 276 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 #5900 is a reply to message #5823] |
Thu, 31 January 2019 04:27 |
bingo600
Messages: 16 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
|
|
|
|
|
|