RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » Superfast Multicomp implementation!!
Superfast Multicomp implementation!! [message #5567] Thu, 22 November 2018 01:02 Go to next message
JonB is currently offline  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 #5568 is a reply to message #5567] Thu, 22 November 2018 04:16 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
Both Cyclone II and Cyclone IV miniboards are fitted with a 50 MHz crystal, limiting the 'processor' clock to 25 MHz.
However, using the built in PLL the system clock can be increased to 90(+) MHz (see this thread: Multicomp Cyclone II-C - 6809 running 90MHz via internal pll [message #1260]Wink
but you need faster SRAM to make it work, possibly using an DIP-SOIC adapter discussed some time ago . (this works for both Cyclone implementations)

You can implement a limited graphical capability in the on-board text display (like the TRS-80) using graphical characters. i.e. extend the character ROM to include these and use escape codes to display them. This will probably not fit in the Cyclone 2 footprint of Grants design, unless you remove the BASIC interpreter from ROM.

When using the serial interface you already have all the graphical capabilities your terminal provides.

Rienk




Re: Superfast Multicomp implementation? [message #5569 is a reply to message #5568] Thu, 22 November 2018 06:19 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
OK, so I have a Cyclone II-C board which I bought over a year ago and I will implement that first. As I have not bought the 2x512k SRAM chips yet (it's currently running using jumper wires and a 128k SRAM I can look to replace those later. I'll have a look at the thread you mentioned as well, because this is pretty well what I am looking for.

As to the built in BASIC, it's not necessary for my use (there is always MBASIC under CP/M) so would be nice to free it up and extend the character set. I've also thought about changing the font as it looks too "PC-ish" for my taste. Problem is, I do not know where to begin...
Re: Superfast Multicomp implementation? [message #5570 is a reply to message #5569] Thu, 22 November 2018 06:57 Go to previous messageGo to next message
rhkoolstar is currently offline  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/fpgaWink, 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 Razz Wink

Rienk

[Updated on: Thu, 22 November 2018 06:58]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5571 is a reply to message #5570] Thu, 22 November 2018 07:10 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
OK, Rienk, thanks.

I'll start with the fast implementation. Bingo's mod requires a 10ns SRAM, only available in a SOIC package, so I am now trying to find a source for the SOIC-DIP adaptor. The link originally posted is down and a search turned up nothing for Micronauts.com but I did find this, which looks similar:

http://www.signalogic.com/index.pl?page=sramadap

I've sent an email to the firm asking for a price with shipping. It looks like it might be applicable here.

Otherwise I would have to re-engineer the adapter board. Presumably not pin to pin, but rewired for the pin names to match. I'll probably end up doing this anyway because it is likely that Signalogic are going to charge a fortune. Get that fabbed at DirtyPCBs with panelling and I could have hundreds of the little blighters on my hands!

Any takers?
Re: Superfast Multicomp implementation? [message #5573 is a reply to message #5567] Thu, 22 November 2018 09:03 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
I bought a cheap Artix-7 board off eBay... It has 512MB of DDR3 RAM onboard... I wonder how fast a Z80 core could run on there?
Re: Superfast Multicomp implementation? [message #5576 is a reply to message #5573] Thu, 22 November 2018 09:56 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
You can ask guus.assmann on this forum. He probably has some SOJ / DIP converters available

If that does not work the included file might be convenient.

Re: Superfast Multicomp implementation? [message #5578 is a reply to message #5576] Thu, 22 November 2018 10:49 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
Indeed it might.. what will I do with 80 of them, though? LOL!
Re: Superfast Multicomp implementation? [message #5580 is a reply to message #5578] Thu, 22 November 2018 11:24 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 127
Registered: October 2015
Location: UK
Senior Member
>> I've also thought about changing the font as it looks too "PC-ish" for my taste. Problem is, I do not know where to begin...

Begin by realising that there is no such thing as ROM on the Cyclone. The character generator "ROM" is a RAM that is initialised from the serial eeprom at reset and that has no write port. You can change it to have a write port and then you just have to work out a way to address it and push in data.

If you aim to mess with the VDU design I recommend that you start with my version, on my 6809 github, as I fixed a bunch of bugs with the scrolling and the ANSI escape handling. I know also that Reink has done a bunch of mods on the z80 version, around using a ROM lookup table to implement keyboard mappings (but, boo hoo, my FPGA has no spare memory resources so I was unable to deploy it)
Re: Superfast Multicomp implementation? [message #5581 is a reply to message #5580] Thu, 22 November 2018 14:15 Go to previous messageGo to next message
JonB is currently offline  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 #5582 is a reply to message #5581] Thu, 22 November 2018 14:42 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
Have a look at Will Sowerbutts SocZ80 system.

http://sowerbutts.com/socz80/

It's on a Papilio Pro FPGA board with DRAM. The T80 (FPGA Z80) CPU itself runs at 128MHz and the RAM is fronted with a 16K cache and MMU.

Apart from emulators on a fast x86 it's the fastest Z80 system I own.

[Updated on: Thu, 22 November 2018 14:57]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5584 is a reply to message #5581] Thu, 22 November 2018 14:46 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
Tge 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

Re: Superfast Multicomp implementation? [message #5587 is a reply to message #5584] Thu, 22 November 2018 21:02 Go to previous messageGo to next message
ale500 is currently offline  ale500
Messages: 44
Registered: April 2018
Member
Getting DDR3 to work needs quite a bit of work(There are tutorial and reference designs). The Artix 7 series are very fast, something like 2 times what you get with a Cyclone 4, of course they are much more recent. It probably has enough block RAM to run a 64 kBytes CP/M machine without external components.
Re: Superfast Multicomp implementation? [message #5588 is a reply to message #5587] Thu, 22 November 2018 22:43 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
The Artix board I have had 225 KB of block RAM and ~50 KB of distributed RAM, so there is enough there for 64K + an MMU with a few pages.
Re: Superfast Multicomp implementation? [message #5589 is a reply to message #5582] Thu, 22 November 2018 23:30 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
etchedpixels wrote on Thu, 22 November 2018 14:42
Have a look at Will Sowerbutts SocZ80 system.

http://sowerbutts.com/socz80/

It's on a Papilio Pro FPGA board with DRAM. The T80 (FPGA Z80) CPU itself runs at 128MHz and the RAM is fronted with a 16K cache and MMU.

Apart from emulators on a fast x86 it's the fastest Z80 system I own.


SocZ80 is promising, but it doesn't look to be well documented and the Papilio Pro is somewhat difficult to acquire and relatively expensive.
Re: Superfast Multicomp implementation? [message #5590 is a reply to message #5589] Fri, 23 November 2018 01:22 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
OK, I've been digging around the font question. I know of a rather clean looking 8x8 font for the Amstrad PCW called SanSerif. There's a picture of it in this PCWWiki forum thread I started showing the "standard" PCW font vs. Sanserif:

http://www.cpcwiki.eu/forum/nc100-nc200-pcw-pda600/lousy-pcw -screen-font/

The font comes wrapped in a short program SANSERIF.COM so you just run it at the CP/M command line to get it to take effect. I pulled the COM file, disassembled it, extracted the font bitmaps and generated Interl HEX files using the HxD hex editor. All that's necessary is to place them in the Multicomp\Components\TERMINAL\ directory, then rename them to CGAFontBoldReduced.HEX and CGAFontBoldExtended.HEX and rebuild the design in Quartus.

As I do not have a working Multicomp to hand (it's in pieces pending arrival of parts for the Cyclone II-C board) I can't test the font just yet. It's possible the characters won't look as good as they do on the PCW if the Multicomp's pixel shape is different, but if anyone wants to try, the files are attached.

Re: Superfast Multicomp implementation? [message #5591 is a reply to message #5590] Fri, 23 November 2018 03:20 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
It works. The actual image is a lot sharper...

index.php?t=getfile&id=1148&private=0
Re: Superfast Multicomp implementation? [message #5592 is a reply to message #5591] Fri, 23 November 2018 04:16 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
I think that'll do nicely... There are a number of other 8x8 fonts that could be used but that's the cleanest looking one IMHO (out of the PCW fonts, at least).

By the way, there are three LEDs on the Cyclone II-C board. The one nearest the SD card is the drive activity light. One of the two others might be a power light. What is the third LED for?
Re: Superfast Multicomp implementation? [message #5594 is a reply to message #5592] Fri, 23 November 2018 06:06 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
Whatever you like. The LEDs are connected to pins 3, 7 and 9 of the FPGA
For your convenience I included the schematics of the miniboard.
Re: Superfast Multicomp implementation? [message #5595 is a reply to message #5591] Sat, 24 November 2018 02:24 Go to previous messageGo to next message
b1ackmai1er is currently offline  b1ackmai1er
Messages: 396
Registered: November 2017
Senior Member
[quote title=rhkoolstar wrote on Fri, 23 November 2018 03:20]It works. The actual image is a lot sharper... quote]

Hi Rienk,Is that the VGA output?

Regards Phil

[Updated on: Sat, 24 November 2018 02:24]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5596 is a reply to message #5595] Sat, 24 November 2018 04:14 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
yes, onto a 8.0" HE080IA-01D CHIMEI INNOLUX TFT LCD Screen Display 1024x768 and a controller board with AV, VGA and HDMI inputs.

I did not try AV, you want to see?

Rienk
Re: Superfast Multicomp implementation? [message #5597 is a reply to message #5596] Sat, 24 November 2018 04:25 Go to previous messageGo to next message
b1ackmai1er is currently offline  b1ackmai1er
Messages: 396
Registered: November 2017
Senior Member
Only if it's easy Smile
Re: Superfast Multicomp implementation? [message #5599 is a reply to message #5597] Sat, 24 November 2018 05:10 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
ok, I turned down the backlight all the way
AV does not scale on this display

index.php?t=getfile&id=1150&private=0
Re: Superfast Multicomp implementation? [message #5600 is a reply to message #5599] Sat, 24 November 2018 05:24 Go to previous messageGo to next message
b1ackmai1er is currently offline  b1ackmai1er
Messages: 396
Registered: November 2017
Senior Member
Thanks! It's so long since I have switch my Multicomp on I have forgetten how to Smile Time to revisit Smile
Re: Superfast Multicomp implementation? [message #5616 is a reply to message #5600] Tue, 27 November 2018 12:53 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Hello, I wrote socz80, it was my first Z80 project, and my first non-trivial FPGA project, what a deep rabbit hole this turned out to be...

The T80 core will clock to quite high speeds (100MHz+ on a Spartan 6). One nice property of the Z80 bus is that address and data signals are asserted and held stable for a cycle or two before the control signals are asserted so designs with timing dependencies on address/data decoding can often be clocked faster than the FPGA timing analysis tools suggest. I suspect there must be some way to express this to the timing tools, but I couldn't figure it out.

If you have enough SRAM on the gate array you'll get a very fast system indeed. If instead you have DRAM on your board you'll quickly find that (a) writing a DRAM controller is no fun at all and (b) modern DRAMs are designed for high speed burst transfers but not for low latency. Your Z80 will be idle virtually all the time, waiting for the DRAM to respond. This is why socz80 employs a relatively large SRAM cache to conceal this latency. I believe the newer Papillio boards have an external large (512KB or 2048KB) and fast (100MHz) SRAM instead of the DRAM, which likely addresses both issues pretty well.

Will
Re: Superfast Multicomp implementation? [message #5620 is a reply to message #5616] Wed, 28 November 2018 02:30 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
Hi Will

Grant's design uses SRAM but it's fairly slow at 55ns. In a separate thread user Bingo600 used a PLL in the Cylcone II to generate clock frequencies of 90Mhz and above. He discovered that the 6809 processor implementation (an optional piece of Grant's Multicomp design) can be clocked to 90Mhz with faster SRAM, so I wanted to see if the same could be done with the Z80 core. His thread is here:

https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;amp ;th=98&goto=1263

..though unfortunately he doesn't post his VHDL, and as a bit of a beginner with this I don't know where to start.

[Updated on: Wed, 28 November 2018 02:31]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5621 is a reply to message #5584] Wed, 28 November 2018 03:08 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
rhkoolstar wrote on Thu, 22 November 2018 14:46
Tge 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 #5622 is a reply to message #5621] Wed, 28 November 2018 08:06 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
On James Moxhams website http://www.smarthome.jigsy.com/fpga under VHDL you will find a Cyclone IV solution with the PLL implemented.
This is for a Cyclone IV miniboard with a 25 MHz oscillator (the so called blue miniboard)
The VHDL for the Cyclone IV very closely resembles the one for a Cyclone II

In the file Max-Scane-Sept-23-2015 you will find PLLto50.vhd as well as the definition in the main file CycloneIVb.vhd under SYSTEM CLOCKS
You can insert a PLL with a wizard too.

As you probably guessed, this is Max Scanes work.

This should set you on the right track for now

Rienk
Re: Superfast Multicomp implementation? [message #5623 is a reply to message #5622] Wed, 28 November 2018 08:43 Go to previous messageGo to next message
JonB is currently offline  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?Wink

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 #5624 is a reply to message #5623] Wed, 28 November 2018 09:31 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
I also found out why the drive LED wasn't lighting up. The resistor values were too high. I've changed them from 5R6 to 150R and all's well.
Re: Superfast Multicomp implementation? [message #5625 is a reply to message #5624] Wed, 28 November 2018 11:34 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
Personally I don't use an RTC. I use an ESP8266 serial WiFi module on one of the UARTS. It feeds time via NTP.
Re: Superfast Multicomp implementation? [message #5626 is a reply to message #5625] Wed, 28 November 2018 12:02 Go to previous messageGo to next message
nealcrook is currently offline  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 Go to previous messageGo to next message
JonB is currently offline  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 #5628 is a reply to message #5627] Wed, 28 November 2018 14:17 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 127
Registered: October 2015
Location: UK
Senior 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

yes, it was added at my request and cunningly shoe-horned in by James. It is supported.. in my 6809 design ;-)

Here's the 6809 code; its structure and algorithms may be some some interest. For nitros I chose to make this a command-line utility that can read the RTC and set the system time; that avoided increasing the sode of the driver (or in your case the BIOS)

Neal.
https://sourceforge.net/p/nitros9/code/ci/default/tree/level 1/cmds/mc09rtc.asm

Re: Superfast Multicomp implementation? [message #5633 is a reply to message #5628] Wed, 28 November 2018 23:18 Go to previous messageGo to next message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
Thanks, Neal, it looks useful. Dragon, eh? I have one sitting on a shelf but it is only a 32.

I think adding RTC support to CP/M will be a nice little project. Did you write VHDL for it too?
Re: Superfast Multicomp implementation? [message #5643 is a reply to message #5633] Thu, 29 November 2018 14:36 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 127
Registered: October 2015
Location: UK
Senior Member
I bought a dragon thinking it would be fun and would cure my 6809 craving, but I was disappointed with its keyboard and video output and it stayed in the cupboard. Once I built my multicomp that dragon went back the way it had co
me (ebay!!Wink

I ported nitrOS9 to the multicomp and that's the only place where I've used the RTC. I ought to add support for it to my FLEX port as well..
Re: Superfast Multicomp implementation? [message #5649 is a reply to message #5643] Fri, 30 November 2018 00:06 Go to previous messageGo to next message
JonB is currently offline  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 Go to previous messageGo to next message
JonB is currently offline  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:


  1. With 25Mhz CPU, 1Mhz SPI clock, 268 seconds
  2. With 25Mhz CPU, 25Mhz SPI, 107 seconds
  3. With 33Mhz CPU, 25Mhz SPI, 82 seconds
  4. With 33Mhz CPU, 50Mhz SPI, 82 seconds
  5. With 33Mhz CPU, 66Mhz SPI, 82 seconds
  6. With 33Mhz CPU, 75Mhz SPI, boot fail
  7. 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!Wink 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

Re: Superfast Multicomp implementation? [message #5652 is a reply to message #5651] Fri, 30 November 2018 05:05 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
the spec for a SDSC states:
Quote:
the maximum SD Bus speed is specified by the
maximum SD clock frequency (25 [MB/sec] = 25000000 [Byte/sec] at 50 MHz) and data size is based
on memory boundary (power of 2).

You are probably driving the card out of spec in cases 5-7 (nothing wrong with that but ymmv)

Take care to mount the RAM chips the 'wrong way around' on the adapter cards when you get them. I.E look carefully at the footprint.
Re: Superfast Multicomp implementation? [message #5654 is a reply to message #5652] Fri, 30 November 2018 06:14 Go to previous messageGo to previous message
JonB is currently offline  JonB
Messages: 92
Registered: August 2016
Location: UK
Member
Oh yes, I see what you mean, pin 1 indicator (a circle, oddly enough) is at the bottom... thanks!

Regarding the SD clock, why might it work at 50Mhz but not yield any performance increase on a major bit of disk I/O over 25Mhz? Do you think it's the CPU speed holding it back?
Previous Topic: What is a up and running kiss-68030 worth?
Next Topic: MSX1 With Old Fashion Dram


Current Time: Fri Mar 29 00:58:55 PDT 2024

Total time taken to generate the page: 0.00981 seconds