Superfast Multicomp implementation!! [message #5567] |
Thu, 22 November 2018 01:02 |
JonB
Messages: 92 Registered: August 2016 Location: UK
|
Member |
|
|
Hi
I've been looking at some of the Multicomp implementations on the Wiki and wondering what the difference is, apart from the obvious (such as multiple serial ports). What I am looking for is a really fast CP/M FPGA machine. At the moment I have a standard Multicomp exactly per Grant's design running at 25Mhz which is pretty zippy, but I do wonder how much quicker it could be.
I saw a tidy looking board here: https://www.retrobrewcomputers.org/doku.php?id=builderpages: rhkoolstar:start - that uses a Cyclone IV breakout board. I'd like to ask, is it any faster than the Cyclone II or is it just a matter of providing more space / pins?
There was another thread discussing Cyclone IV Multicomp designs and wondering about adding graphics and other capabilities: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;amp ;th=79&start=0&
Did anything come of this? I did suggest to Grant that the ROM BASIC in his original design could be dropped in favour of a limited graphical capability on the Cyclone II but I don't have the expertise to do it.
Also, on the subject of performance, might a more efficient core like the NextZ80 be used for this? Grant's design uses a core called T80 at the moment.
Sorry, lots of questions! I've been playing with real CP/M hardware fro quite a while now and only just coming back to the Multicomp.
Thanks
JonB
[Updated on: Tue, 08 January 2019 03:13] Report message to a moderator
|
|
|
|
|
Re: Superfast Multicomp implementation? [message #5570 is a reply to message #5569] |
Thu, 22 November 2018 06:57 |
rhkoolstar
Messages: 276 Registered: October 2015
|
Senior Member |
|
|
You start by reading other peoples work. and figuring out how it works.
also find and install a compatible Quartus environment for your board (version 13.0 web edition for Cyclone II), which I guess you already have.
Get a working system (from Grants site, the wiki, or from here: http://www.smarthome.jigsy.com/fpga, preferably as close to what you are aiming for, then implement small changes, and make them work, learning as you go.
If you are just looking for a fast CP/M you can combine any implementation with the PLL by Bingo (originally Max Scane)
for implementing graphical features you have to dive in the SCBTextDisplayRGB code and figure out how that works
(or if you are lazy, you can find someone to do it for you, something I cannot recommend
Rienk
[Updated on: Thu, 22 November 2018 06:58] Report message to a moderator
|
|
|
|
|
|
|
|
Re: Superfast Multicomp implementation? [message #5581 is a reply to message #5580] |
Thu, 22 November 2018 14:15 |
JonB
Messages: 92 Registered: August 2016 Location: UK
|
Member |
|
|
OK, but there is non volatile memory somewhere onboard, or where would the boot loader come from?
Grant talks about ROM on his web page but looking at the files in the ROM directory there is no actual data. So it is, I guess, defining the ROM chip but not its contents. However:
altsyncram_component : altsyncram
GENERIC MAP (
clock_enable_input_a => "BYPASS",
clock_enable_output_a => "BYPASS",
init_file => "../ROMS/Z80/BASIC.HEX",
intended_device_family => "Cyclone II",
lpm_hint => "ENABLE_RUNTIME_MOD=NO",
lpm_type => "altsyncram",
numwords_a => 8192,
operation_mode => "ROM",
outdata_aclr_a => "NONE",
outdata_reg_a => "UNREGISTERED",
widthad_a => 13,
width_a => 8,
width_byteena_a => 1
)
The init_file has the actual content. Do I take it, then, that the Quartus compiler reads the file (BASIC.HEX) and somehow puts it on the FPGA?
Clearly I've much to learn!
[Updated on: Thu, 22 November 2018 14:15] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Superfast Multicomp implementation? [message #5621 is a reply to message #5584] |
Wed, 28 November 2018 03:08 |
JonB
Messages: 92 Registered: August 2016 Location: UK
|
Member |
|
|
rhkoolstar wrote on Thu, 22 November 2018 14:46Tge quartus compiler stores the configuration on the EPCS4 eeprom.
Every time you power up the machine the Cyclone chip is configured from that file.
in short, 8192 bytes or RAM are initialized and loaded with the BASIC file data.
the operation mode is set to ROM (no write port), so for all practical purposes you now have a programmed ROM in your system
There is a 'wizard' in the Quartus environment that can produce the above file, from specifications you enter in it
Thanks, Rienk.
I've just completed removal of the NASCOM BASIC from the boot ROM. Now I have a 1K monitor, which I have fitted into a new 1k ROM device in Quartus, and it has reduced total memory bits used from 89% to 40%. I now want to apply the changes to the VGA and keyboard implementation to free up some logic elements. Small steps..
[Updated on: Wed, 28 November 2018 03:09] Report message to a moderator
|
|
|
|
Re: Superfast Multicomp implementation? [message #5623 is a reply to message #5622] |
Wed, 28 November 2018 08:43 |
JonB
Messages: 92 Registered: August 2016 Location: UK
|
Member |
|
|
Thanks Rienk, I will check it out now.
I have another question about the RTC module that is fitted to the Cyclone II-C carrier board. As you might imagine, I am looking for an interface implementation for it! There is an RTC in Max's zipfile but I think it is implemented inside the FPGA as a counter for one of the clocks (counts down each millisecond), rather than communicating with an external board.
The RTC itself is a DS1302 which is capable of keeping time, day, month, year and accounts for leap years up to 2100 AD which really ought to be enough (have we heard that before, I wonder?
So I would like to build out some VHDL that communicates with this module and exposes a set of I/O ports to the operating system so that I can get and set the date/time. It might be a good project to help me learn stuff. I think I will need to free up space by implementing the VGA optimisations first...
[Updated on: Wed, 28 November 2018 08:59] Report message to a moderator
|
|
|
|
|
Re: Superfast Multicomp implementation? [message #5626 is a reply to message #5625] |
Wed, 28 November 2018 12:02 |
nealcrook
Messages: 127 Registered: October 2015 Location: UK
|
Senior Member |
|
|
>> So I would like to build out some VHDL that communicates with this module
the DS1302 uses an SPI interface. SPI is an interface that has no proper/consistent specification unlike, for example, I2C -- however, the behaviour is clearly described in the data sheet. It is simple enough and slow enough and used infrequently enough that you can just knife-and-fork it with GPIO under software control. In my 6809 design I build a GPIO module which was designed to occupy a minimal memory space (but you're on a Z80 so you have an independent I/O space to play with). I can oint you at some sample code but it's in 6809 assembler...
Neal.
[Updated on: Wed, 28 November 2018 12:03] Report message to a moderator
|
|
|
Re: Superfast Multicomp implementation? [message #5627 is a reply to message #5626] |
Wed, 28 November 2018 13:45 |
JonB
Messages: 92 Registered: August 2016 Location: UK
|
Member |
|
|
Well, it is fitted to a specific port on the Cyclone II-C carrier board called "RTC" in the schematic, so I hoped it was already supported. But no matter. It uses three lines which are physically wired to pins 40, 41 and 42 of the Cyclone II. As it appears to have a synchronous interface and you just toggle the bits to/from the data pin by flapping the clock pin about, it shouldn't matter whether or not it's driven at a specific clock speed - as long as I don't exceed its maximum (whatever that is). So what I need to do, I think, is modify the output latch VHDL code I found here and map it to a Z80 I/O port; then I can write a bit banging driver for it to put in the BIOS. The good thing about this is it should not use many of the limited remaining LEs in the Cyclone, as all the cleverness will be in the CP/M BIOS.
[Updated on: Wed, 28 November 2018 13:52] Report message to a moderator
|
|
|
|
|
|
Re: Superfast Multicomp implementation? [message #5649 is a reply to message #5643] |
Fri, 30 November 2018 00:06 |
JonB
Messages: 92 Registered: August 2016 Location: UK
|
Member |
|
|
But to use the RTC in the Multicomp you must have needed to define some VHDL to set up the connection between the 6809 and RTC? That's what I would like to take a look at.
Meanwhile I am having fun with the PLL wizard. I'm setting one up that runs at the normal clock speed (input = clk, output multiplier = 1) and once I have this going I can try to ramp it up. I'm not expecting miracles until I have the fast RAM fitted. It occurred to me that one might use a PLL as a clock divider to remove some of the clock code in Microcomputer.vhd (thus saving some LEs). I also achieved a small improvement by changing the compilation settings in Quartus II. It has a sort of "optimisation adviser" that suggests better settings.
At the moment the PLL isn't working but I will persist.
[Updated on: Fri, 30 November 2018 00:11] Report message to a moderator
|
|
|
Re: Superfast Multicomp implementation? [message #5651 is a reply to message #5649] |
Fri, 30 November 2018 04:30 |
JonB
Messages: 92 Registered: August 2016 Location: UK
|
Member |
|
|
Got the PLL running and feeding the CPU and SD card clocks directly, so the clock processing code in Microcomputer.vhd for both clocks is deleted.
Some performance results, using a fairly large C compilation SUBMIT job as a test:
- With 25Mhz CPU, 1Mhz SPI clock, 268 seconds
- With 25Mhz CPU, 25Mhz SPI, 107 seconds
- With 33Mhz CPU, 25Mhz SPI, 82 seconds
- With 33Mhz CPU, 50Mhz SPI, 82 seconds
- With 33Mhz CPU, 66Mhz SPI, 82 seconds
- With 33Mhz CPU, 75Mhz SPI, boot fail
- With 33Mhz CPU, 100Mhz SPI, boot fail
Results 4 and 5 are odd - perhaps the CPU becomes the bottleneck when the SPI clock is too fast?
This is using the ASC SRAM (slow) and standard SD controller VHDL, so it applies to Grant's original design. The card is a generic 2GB MicroSD (not SD-HC) so I could try a high speed card and the patched SD controller code, but the lack of performance increase above 25Mhz SPI suggests it isn't worth doing. The CPU clock cannot be pushed higher at this time (it won't start up if faster than 33Mhz), possibly due to the low SRAM access speed.
So, for the time being I am running with configuration 3 and it feels very snappy indeed. The next step is to fit fast memory and ramp up the CPU clock some more. I received some RAM adaptor cards this morning (thanks Guus! but the ICs are still in the post.
In the meantime, I will look at the RTC implementation.
[Updated on: Fri, 30 November 2018 04:30] Report message to a moderator
|
|
|
|
|