RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » Superfast Multicomp implementation!!
Re: Superfast Multicomp implementation? [message #5655 is a reply to message #5651] Fri, 30 November 2018 06:24 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
jonb wrote on Fri, 30 November 2018 05:30
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


JonB,
Could you publish the files you used for the benchmark? I have a 22MHz Z80 SBC with a compact flash disk. I'm curious to know how that compares with a SD disk.

I also found an Altera Stratix board (1S25) made by Parallax (the Propeller people) around 2004. The Stratix FPGA has large internal RAM blocks (128KB) so I can build a Z80 SBC with T80 VHDL, RAM blocks and SPI interface to SD disk without adding any external components. Something to play around with over the holiday.
Bill

Re: Superfast Multicomp implementation? [message #5656 is a reply to message #5654] Fri, 30 November 2018 06:27 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
Not odd, reversing the chip makes routing the board easier.
This way the adapter board should fit inside the DIP footprint so you can use two of them in adjacent sockets

Yes, the SD card routine in BIOS uses many more CPU cycles to read or write a byte.
Also there is overhead for calculating and setting the Logic Block Address for every block of 512 bytes.
You can only speed this up by clocking the CPU higher or making the BIOS code more efficient.
Re: Superfast Multicomp implementation? [message #5657 is a reply to message #5656] Fri, 30 November 2018 07:13 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Ah right, I should have considered the blocking/deblocking algorithm and LBA derivation. I've used this code myself in an IDE driver.

@Bill, I will have to do a bit of "Kermiting" to get it uploaded. It's a CP/M port of stevie (a vi clone written for the Atari ST) which is quite usable on a 25Mhz CP/M box like the Multicomp, but painfully slow on a real 4Mhz Z80 box. The code compiles with Aztec C, which is on Drive C User 2 of the Multicomp demo disk image. Just copy the files in the archive to this location then do SUBMIT BUILDALL and time the result. You also need a patched version of SUBMIT.COM as the normal one doesn't like running off a non boot drive. I've attached a copy.

[Edit: Darn it. Kermit is not happy sending from the Multicomp but it receives just fine, so I'll go out on a limb and post the original P2000C source, which should work on the Multicomp.]

[Edit 2: STevie does not display CP/M text files correctly because it is not expecting CR/LF (the DOS and CP/M end of line sequence). So instead it does the carriage return, but shows the line feed as a hex character [0x0D]. You can still edit files, though; even binary (that's why there is a representation of a non printable character). If you use TYPE to look at any of the source files, you will find they don't contain CRs.]



  • Attachment: STevie.zip
    (Size: 18.56KB, Downloaded 53 times)
  • Attachment: SUBMIT.zip
    (Size: 1.35KB, Downloaded 49 times)

[Updated on: Fri, 30 November 2018 07:18]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5658 is a reply to message #5656] Fri, 30 November 2018 07:21 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
rhkoolstar wrote on Fri, 30 November 2018 06:27
Not odd, reversing the chip makes routing the board easier.


I meant it was odd to use a circle on the silkscreen to indicate pin 1. It's usually a dot, or a notch in the outline. But then, I've very little experience with these SMD chips. Let's hope they arrive quickly... can't wait!

Very Happy
Re: Superfast Multicomp implementation? [message #5660 is a reply to message #5658] Fri, 30 November 2018 08:22 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 228
Registered: October 2015
Senior Member
I am surprised you got the SPI as fast as you did. SD is not rated for that high a clock rate so the fails are no surprise (I'm surprised you got over about 33MHz working). The faster SD modes are multi-bit wide rather than faster clock so need a different connection arrangement. The really fast ones also do link tuning and other deep magic.

By way of comparison. On a real 3.5MHz Z80 (ZX Spectrum) the highest raw rate I can get off an SPI (ZXMMC) card is 218KBytes/second, and the highest rate I can get off ATA is the same. In both cases it comes down to how fast the ini instruction runs. Even in PIO0 the upper limit for the transfer rate off an ATA card is 3.3MBytes/second so a 25MHz Z80 is physically not capable of reaching the transfer speed. On the ZXMMC it's arranged so that straight ini and outi loops can drive the SPI. You are fundamentally bounded by how fast you can issue ini instructions even if in unrolled loops. The only way to beat that limit would be to implement a DMA engine.

The performance is also bounded the operating system overhead. CP/M is not optimized for large fast I/O (CP/M 3 is a chunk better as it can use 512 byte sectors directly, it also allows multi-block read/write but most apps don't use the feature). 218KByte/second does not translate to anything remotely like that in real use on CP/M or indeed on any other OS.

On the LBA mapping - if you are cunning with your disk geometry the LBA translation becomes trivial. I prefer not to - but to take the hit and also add partition table support.

Alan
Re: Superfast Multicomp implementation? [message #5662 is a reply to message #5660] Fri, 30 November 2018 09:02 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Thanks for the explanation, Alan. I'll see what happens when I can ramp up the CPU speed, then.

Meanwhile, tried the updated TERMINAL module from http://www.smarthome.jigsy.com/fpga. I hate to say this, but it doesn't seem to work properly on the Cyclone II. The screen gets corrupted when starting up WS.COM. I've checked the declaration in my top level VHD file (Microcomputer.vhd) and it is the same as the corresponding declaration in CycloneIV.vhd. So for now I reverted back to the original module.

Despite these minor problems, I am very pleased with the way it is turning out.

[Updated on: Fri, 30 November 2018 09:04]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5663 is a reply to message #5662] Fri, 30 November 2018 10:42 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 119
Registered: October 2015
Location: UK
Senior Member
>> 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.

yes, the code is here:

https://github.com/nealcrook/multicomp6809/blob/master/multi comp/Components/GPIO/gpio.vhd

and you may also need to refer to the top-level hookup here:

https://github.com/nealcrook/multicomp6809/blob/master/multi comp/MicrocomputerPCB/Microcomputer.vhd

Neal.
Re: Superfast Multicomp implementation? [message #5664 is a reply to message #5663] Fri, 30 November 2018 10:57 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Great, Neal, I'll check it out immediately.

😁
Re: Superfast Multicomp implementation? [message #5666 is a reply to message #5664] Fri, 30 November 2018 14:37 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
JonB,
Thanks for the files. I compiled it on my 22MHz Z80 with compact flash disk. The time to run buildall.sub is 103 seconds. So if this is a 25MHz equivalent Z80, it should run about 90 seconds, so CF still has a significant advantage over SD with SPI clocking at 25MHz.

I see what you meant by STevie being slow. When editing a new file it seems OK, but when I insert new lines in the middle of a modest size file, the screen refresh is slow. Hardware handshake for the serial port is required or I can easily overrun the input buffer. The carriage return is weird just like you've said.
Bill
Re: Superfast Multicomp implementation? [message #5667 is a reply to message #5664] Fri, 30 November 2018 14:39 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 119
Registered: October 2015
Location: UK
Senior Member
Out of interest, how big is the vi executable created from STevie? Bingo600 and I worked on resuscitating a vi clone in C under 6809 FLEX -- changing it to support ANSI control sequences. The final executable was ~15Kbytes. It had the usual restriction that the file to be edited had to fit in memory. Perofmance-wise it runs fine on a ~25MHz 6809.

Neal.
Re: Superfast Multicomp implementation? [message #5668 is a reply to message #5667] Fri, 30 November 2018 14:49 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
vi.com is 28K.
Bill

PS, I have not used vi for 20 years, my head doesn't remember the commands but my fingers do! It is a weird sensation puttering around the screen; My fingers know what to do but my mind is blank, just observing how cursors magically moved around, text added and file saved and exited. It is like magic!
Re: Superfast Multicomp implementation? [message #5669 is a reply to message #5668] Sat, 01 December 2018 02:55 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 119
Registered: October 2015
Location: UK
Senior Member
>>my head doesn't remember the commands

me too. My Children use that "muscle memory" to play Piano. Mine seems to be allocated to keystrokes for emacs (and, sadly, WordStar)
Re: Superfast Multicomp implementation? [message #5670 is a reply to message #5669] Sun, 02 December 2018 02:35 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
More fun & games: I have integrated the TERMINAL component from Max Scane's September 23 2015 zip file and it's working nicely. Now I have the following usage on my Cyclone II:

Logic Elements 85%
Combinatorial functions 81%
Dedicated Logic registers 25%
Total memory bits 45%

So, I think there is enough space to implement some more goodies.

Regarding vi.com (well, "stevie.com" really).. I'm the same. Struggle with any other text based editor, especially Wordstar. The new bindings in the TERMINAL component certainly help, though. If I could just recall the "save" command... (^Ks, how arcane).

There are other vi implementations; one in particular can be found on comp.os.cpm which is quick enough but it is too big to be any use on CP/M - you can edit a 6k file maximum. I set STevie to 16k which allows me to edit its source files. STeveie is slow because of the way it determines how to refresh the screen. It's got a double buffer and compares one against the other in order to work out what's changed. This is also how ncurses works on Linux (and curses before that on other *nix systems) but of course it runs on faster hardware. STevie also does not take advantage of the termianl escape sequences other than clear screen and cursor location, so a rewrite is definitely on the cards...

[Updated on: Sun, 02 December 2018 02:45]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5671 is a reply to message #5667] Sun, 02 December 2018 04:33 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
nealcrook wrote on Fri, 30 November 2018 14:39
Out of interest, how big is the vi executable created from STevie? Bingo600 and I worked on resuscitating a vi clone in C under 6809 FLEX -- changing it to support ANSI control sequences. The final executable was ~15Kbytes. It had the usual restriction that the file to be edited had to fit in memory. Perofmance-wise it runs fine on a ~25MHz 6809.

Neal.


Hi Neal, could you post the [a link to] source code, please? I'd like to try it on the Z80 Multicomp.. Thanks!
Re: Superfast Multicomp implementation? [message #5672 is a reply to message #5671] Sun, 02 December 2018 05:32 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 119
Registered: October 2015
Location: UK
Senior Member
>> the TERMINAL component from Max Scane's September 23 2015 zip file

be aware that this code inherits a bunch of bugs in the escape sequences from Grant's original. You can see a list of bugs and fixes in the git log for my version:

commit 81d4ca77b268c411e3170dd84c65550735597c93
Author: nealcrook <neal@pippaluk.org.uk>
Date:   Fri Nov 4 18:29:30 2016 +0000

    Complete the fix to the line insert and line delete flows. The previous fixes
    did not work in the corner-case of insertion or deletion on the bottom line.
    In fixing that, I made some other adjustments so that the insert and delete
    copy always proceeds from 0 to line end; this should reduce the number of
    comparators needed because it makes the behaviour consistent with the line
    clear flow.
    
    Also, a few white-space changes.

commit f5c9a12364bb8043379da1ab1ac7edd8bd62772e
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Mon Jul 18 22:45:31 2016 +0100

    Make ESC key generate 0x1b. This required taking F11 and F12 out of the
    set of "special keys" that generate hardware signals out rather than
    key-codes (but that is no loss because this design does not use that
    capability.
    Fix line insert and line delete - previously the data copy was happening
    in the wrong state so that, for example, insert would corrupt the lower part
    of the screen with a single repeated character. That may be a bug that I
    introduced when I switched this piece of the design to single-edge clock.
    Previously, insert copied characters starting at the right and ending at the
    left, while delete copied characters starting at the left and ending at the
    right. There was no reason for this difference and they both now work in
    the same direction (right to left).
    Both line insert and line delete misbehave on the bottom one or two lines
    (lines 24 and/or 25). Don't think I caused this bug. The fix will require
    a re-jig of the insert and delete loops.

commit 5cf41525c35821c4bdbde98c8e97e3c784ce2000
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Sat Jun 11 19:32:23 2016 +0100

    Tweak keyboard mapping so that ESC key generates 0x1b (escape).

commit aa7cc221554c3c03ba5a4e8a19ed915bd055dc0d
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Tue Mar 22 23:14:09 2016 +0000

    Modified keyboard map to add support for 102-key keyboard #~ key
    (key42) and \| key (key45). This was a trial-and-error process as
    the scan codes for these keys are not documented clearly.

commit f44d4eddb40ce8f449fdc5f2009d3dc53789ffdc
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Sat Feb 13 15:55:01 2016 +0000

    Clean up the functional reset generation in the UART to make it
    glitch-free. Extent its use to reset the pointers of the input FIFO.
    Add glitch-free functional reset generation to the VDU. Use it to reset
    the pointers of the keyboard input FIFO.
    Previously, after running CUBIX and pressing "RESET" could not start up
    BUGGY successfully: the PS/2 and/or UART input would be non-responsive.
    My theory is that the pointers were getting messed up and these reset
    changes are intended to fix that. Both VDU and UART now support the 6850
    "master reset" of writing 3 to the control register.
    Added "master reset" of serial port in BUGGY. Still need to do the same
    in FLEX.

commit df18391019efdc4ea5eda80a43e30296995ee945
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Fri Jan 1 20:26:13 2016 +0000

    Bug-fix to ESC[K (erase to end of line). Previously, the cursor position
    would be corrupted (cursor sent HOME) by thsi sequence. Now the cursor
    position is preserved.

commit e9ffefd3ceab3b1e3e7e04ffe37569c6d0a700c5
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Fri Jan 1 19:38:25 2016 +0000

    Whitespace changes and comment fix-ups; no functional changes.

commit 940f7594431edec8da26feaf59fc3634b53f07a0
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Tue Sep 22 21:47:12 2015 +0100

    Couple of whitespace changes.
    
    Main change is to use a function to truncate an 8-bit value (expressed in hex)
    to a 7-bit value. This allows the keymap to be represented in a slightly
    clearer way. Added comments to the keymap to show the keys and to describe
    the format.

commit c302e303647dc8936a2b4cd36f54d497e0af0ca7
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Tue Sep 22 20:23:27 2015 +0100

    Change all processes to use rising edge clock. Previously they used a mixture
    of rising and falling, and this made the timing very tight (did not close
    timing with 50MHz clock). Moving everything to rising clock has no impact
    on functional performance; the pixels just come out 2 cycles later. Has a
    great beneficial effect on timing though. This effectively re-pipelines the
    output which required one counter comparator to change.
    
    Fix functional bug brought to light by CUBIX. CUBIX does line endings as
    LF CR rather than the usual CR LF. There was a bug in the display logic on
    scroll: the line was cleared from the cursor position to the end rather than
    from the start of line to the end. After a CR the cursor position was always
    at the left so this bug was hidden. The effect of the bug was a wierd effect
    on the bottom line which then scrolled up the screen. Took *ages* to work out
    what was going on but, once spotted, was very straightforward to fix.

commit ba6cbea7ebc14b49863ed95ce8bcc0710130e2d3
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Tue Sep 22 20:15:25 2015 +0100

    No functional change. Add names to all the processes, to aid debug in the
    simulator. Add more comments to the keyboard decoding code.

commit bc78e557e263de2faadd79041807cf5accbd070b
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Tue Sep 22 20:09:30 2015 +0100

    No functional change. Two groups of syntax changes so that the design
    will load into modelsim without overflow error and without "Actual
    expression of formal is not globally static"

commit 5bf7eb860f9d2991a1067f9fd85e8e4556b383d5
Author: Neal Andrew Crook <neal@pippaluk.org.uk>
Date:   Tue Sep 22 19:50:37 2015 +0100

    Grant Searle's original sdcard and terminal VHDL code, posted with his
    permission.

Re: Superfast Multicomp implementation? [message #5673 is a reply to message #5672] Sun, 02 December 2018 06:42 Go to previous messageGo to next message
nealcrook is currently offline  nealcrook
Messages: 119
Registered: October 2015
Location: UK
Senior Member
Here are the sources for ved2, which I extracted from flex drive 2 of the latest sd card image for multicomp09 (multicomp09_sd_apr2017.zip)

IIRC this could compile and run on a Linux system and so the C must be "reasonably" modern (but probably more K&R than ANSI). However, I could not get that to work today. I will look and see if I have some additional files on another machine.

I'm not sure how much work will be involved in getting this to work under your z80 C compiler but if you do get it running it will be interesting to compare code size and performance against the 6809 version

Neal
  • Attachment: ved2.zip
    (Size: 33.92KB, Downloaded 45 times)
Re: Superfast Multicomp implementation? [message #5676 is a reply to message #5673] Sun, 02 December 2018 16:12 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 228
Registered: October 2015
Senior Member
Be aware that Harry Suckow (who ran Manx and owns the rights) has only given permission for educational and fair use redistribution of Manx products rather than abandoning them.

Alan
Re: Superfast Multicomp implementation? [message #5680 is a reply to message #5676] Tue, 04 December 2018 01:53 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Fun with the RTC..


index.php?t=getfile&id=1172&private=0


This is a port of Neal's 6809 program to CP/M that reads the DS1302 RTC and sets the Multicomp's internal RTC. As I haven't added the internal RTC VHDL yet, this program reads the time / date from the chip and dumps it as hex.

Or not.. I think it's broken... Laughing
  • Attachment: DS1302.jpg
    (Size: 38.80KB, Downloaded 422 times)
Re: Superfast Multicomp implementation? [message #5691 is a reply to message #5680] Thu, 06 December 2018 03:22 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
I've now built a "fast RAM" board using a Samsung K6R4008 and SOIC36 - DIP adapter board. Nasty tiny soldering.

It doesn't work, and what's more, it seems to have damaged the Cyclone board.

I've attached a picture. In the foreground is the board with chip mounted per the advice given here (chip to be mounted upside down relative to IC socket). Behind it is another board, unpopulated, showing the circle that indicates Pin 1 of the SOIC package. Just want to confirm I have built it correctly, because Bingo600's adapter board has the IC the other way round. A different adapter, but I thought I'd better check.


Comments?

.
  • Attachment: IMG_5059.jpg
    (Size: 584.24KB, Downloaded 56 times)

[Updated on: Thu, 06 December 2018 03:26]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5693 is a reply to message #5691] Thu, 06 December 2018 05:40 Go to previous messageGo to next message
b1ackmai1er is currently offline  b1ackmai1er
Messages: 270
Registered: November 2017
Senior Member
Holy cow, how did you even solder that! I would never be able to do that.

I thought the carrier boards were meant for TSOP chips like this ... ???


I thought the chip had to be reversed on the carrier board ... so check if you've inserted it the wrong way around in your multicomp or if the chip has to be facing down ... i.e. carrier pins should be sticking out the other way ?

Regards Phil.

[Updated on: Thu, 06 December 2018 05:43]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5694 is a reply to message #5693] Thu, 06 December 2018 05:46 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Same way that Bingo600 did, I guess. Yes, they do look like they should accept TSOPs.

You've linked to a 44 pin TSOP but the carrier board takes a 36 pin package, so that particular chip won't fit.

I wonder if I have fake ICs?

The chip is mounted upside down - that is, relative to the orientation of the notch on the socket, Pin 1 of the chip is furthest away from the notch. I'm having doubts that that is the right way to mount it.

[Updated on: Thu, 06 December 2018 05:52]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5695 is a reply to message #5694] Thu, 06 December 2018 05:54 Go to previous messageGo to next message
b1ackmai1er is currently offline  b1ackmai1er
Messages: 270
Registered: November 2017
Senior Member
Yes sorry, I just checked the original post and my multicomp and that orientation does look right.

Your layout does match Bingo600's as you say.

Have you tried checking for hidden solder bridges.

I am keen to try this myself on an ECB-RAM Floppy board

Regards Phil

[Updated on: Thu, 06 December 2018 06:27]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5696 is a reply to message #5695] Thu, 06 December 2018 08:20 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Hi Phil

Yes, I checked adjacent legs to see if there were any shorts. None found.

It's not the same as Bingo's. His adapter board is designed so that the IC has the same orientation as the DIP socket in the carrier board. But I wasn't sure, so I asked.

I now have another problem. The Cyclone II-C card might be damaged. I am unable to run the Multicomp in it, even with the minimal Microcomputer.vhd (as shown on Grant's site, a 4k Z80 machine running BASIC on the Cyclone board, with no other attachments). This configuration runs fine off the carrier board.

I am also unable to bring up the CPM machine's boot prompt with the Cyclone board on its own (goes without saying it won't run on the carrier board, either). I believe I should get the prompt but go no further on a bare Cyclone II board.

Bit of a nightmare.. will have to go back to first principles again.


[Updated on: Thu, 06 December 2018 08:21]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5698 is a reply to message #5696] Thu, 06 December 2018 10:37 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 256
Registered: October 2015
Senior Member
Hi Jon,

As far as I can see you did everything right. It is a 3v3 36 pin SOJ, connected as it should. Just check the Vss and Vcc lines pin 10 & 27.
Possible failures may include soldering (finicky allright) or bad ic. Really not much more choices here.

Your miniboard failure might be unrelated to the memory chip. I have a defective one, the failure of which is a mystery to me. You can program it, but it just does not work.

Rienk
Re: Superfast Multicomp implementation? [message #5699 is a reply to message #5567] Thu, 06 December 2018 10:54 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
One possible failure maybe mechanical connections. The process of plugging and unplugging memory board disturbed a weak or intermittent joint resulting in failures unrelated to the memory board itself. Visually inspect boards for broken solder joints and conductive particles. Let the board warm up a bit, press and twist the board and see if you observed different behavior.
Bill
Superfast Multicomp implementation? [message #5700 is a reply to message #5699] Thu, 06 December 2018 12:14 Go to previous messageGo to next message
guus.assmann is currently offline  guus.assmann
Messages: 27
Registered: May 2018
Location: Netherlands
Junior Member
Hello,

For my boards, I've soldered the memory chip the same way as you did. The silkscreen is correct.
And if the complete memory adapter is in the multicomp, I can see the Ram-chip.
I'm not sure how you put the adapters in your board.

One thing I can confirm.
If you solder the ram chip 180 degrees wrong on the adapter, it will not work.
However, after removing it and puting it on the right way, my Ram-chip still did work 100% ok.

BR/
Guus
Re: Superfast Multicomp implementation? [message #5701 is a reply to message #5700] Thu, 06 December 2018 13:24 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
OK, so I have the memory chip installed correctly on the adapter. Good. It is plugged into the carrier board same way round as the Alliance RAM chip - with the notch to the edge of the board. This must surely be correct.

The Cyclone miniboard works if I program it with a minimal system (Z80, 4K internal RAM, BASIC). However, If I then plug it into the Cyclone II-C carrier board, it doesn't work. I checked the serial connections, they match and have continuity. Something odd is going on. But I cannot see why I get no monitor with the "full CP/M" configuration (with the miniboard not connected to the carrier board). I should at least see the boot prompt. I have examined the carrier board for damage; I can't see any. But it did flex a lot when I fitted the RAM adapter. Maybe a track got damaged. The programming cable was underneath it at the time and I noticed that some of the IC socket pins had pierced the insulation slightly. When I removed the programming lead it started working again, but has since failed. Maybe another indication of board damage due to flexing?

I've ordered another miniboard. It'll be here by February, I am sure...

Thank you all for your advice, I do appreciate it.

Cheers
JonB

[Updated on: Thu, 06 December 2018 13:29]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5709 is a reply to message #5701] Mon, 10 December 2018 07:51 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
Spent some time over the weekend with the Multicomp.

I reflowed all the joints and reprogrammed the Cyclone. Took a while but it is working now (at full speed - 33Mhz with a 50Mhz SPI clock for the SD card). Phew, that's a relief. I think the moral of this tale is "support the board when inserting RAM chips", because it does not like being bent.

I'm now hoping to get the fast RAM working (still unsure whether they are fake chips). I assume I need to set the jumpers to the 512k setting but are there any VHDL changes required (just for 128k initially)?

[Updated on: Mon, 10 December 2018 07:51]

Report message to a moderator

Superfast Multicomp implementation? [message #5712 is a reply to message #5709] Mon, 10 December 2018 12:17 Go to previous messageGo to next message
guus.assmann is currently offline  guus.assmann
Messages: 27
Registered: May 2018
Location: Netherlands
Junior Member
As per request, a detail of my board.
Notice the position of the red jumpers.
The pins on the Ram adapter boards are quite thin where they sit in the socket.
So no problem there. Soldering was not so easy, but I managed.

BR/
Guus

[Updated on: Mon, 10 December 2018 12:19]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5716 is a reply to message #5712] Mon, 10 December 2018 16:46 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
JonB,
I managed to overclock my 22MHz Z80 to 29.5MHz by raising the voltage to 5.5V. It passes ZEXALL.COM so I thought I'd try the STevie benchmark to see whether it scales proportionally to 29.5MHz with the CF interface. It did the benchmark at 77 seconds and yes, it does scale.
Bill

c>submit buildall

c>CZ WINDOW
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS WINDOW
8080 Assembler Vers. 1.06D

c>CZ NORMAL
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS NORMAL
8080 Assembler Vers. 1.06D

c>CZ MISCCMDS
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS MISCCMDS
8080 Assembler Vers. 1.06D

c>CZ LINEFUNC
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS LINEFUNC
8080 Assembler Vers. 1.06D

c>CZ HEXCHARS
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS HEXCHARS
8080 Assembler Vers. 1.06D

c>CZ CMDLINE
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS CMDLINE
8080 Assembler Vers. 1.06D

c>CZ EDIT
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS EDIT
8080 Assembler Vers. 1.06D

c>CZ MAIN
C Vers. 1.06D Z80  (C) 1982 1983 1984 by Manx Software Systems

c>AS MAIN
8080 Assembler Vers. 1.06D

c>LN -O VI.COM WINDOW.O NORMAL.O MISCCMDS.O LINEFUNC.O HEXCHARS.O CMDLINE.O EDIT.O MAIN.O C.LIB
C Linker Vers. 1.06D
Base: 0100   Code: 6519  Data: 0543  Udata: 1394  Total: 007df4

c>
Re: Superfast Multicomp implementation? [message #5717 is a reply to message #5716] Tue, 11 December 2018 07:18 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
I've built another fast RAM module and I'm happy to say it is working.

I think I may have accidentally fried the other chip by feeding 5v to the 3.3v line on the board (oops). Anyway...

Here are some additional performance results, using the full STevie build as a benchmark:
CPU clock 50Mhz, SD clock 50Mhz: 57 seconds Shocked
CPU clock 55Mhz, SD clock 50Mhz: shows monitor prompt but will not boot CP/M
CPU clock 60Mhz, SD clock 50Mhz: shows monitor prompt but will not boot CP/M
CPU clock 75Mhz, SD clock 50Mhz: will not boot (but reset pops up some characters)
CPU clock 100Mhz, SD clock 50Mhz: will not boot

So it seems that for the time being 50/50 Mhz is as far as I can take the CP/M Multicomp. A faster SD card may allow me to up the SD clock (and / or the CPU clock to 60Mhz), using Neal's SDHC VHDL.

I now have some options to explore:

  • SDHC VHDL for the SD Controller
  • More RTC fiddling
  • Fit a second fast RAM module for 1MB
  • Build out MMUs
  • Try CP/M Plus and the other OS-es that use paged RAM

Insane to think the Multicomp only cost about £30, yet I'm having so much fun with it...

[Updated on: Tue, 11 December 2018 07:23]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5718 is a reply to message #5717] Tue, 11 December 2018 07:57 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
57 seconds! Very cool. I can see the attraction of having a fast processor. There is a snap to it that is very pleasing.

How well does the FPGA Z80 runs ZEXDOC.COM? During my overclocking test of the Z80, I've noticed that a Z80 may fail some ZEXDOC.COM tests but still run up CP/M.

Bill
Re: Superfast Multicomp implementation? [message #5719 is a reply to message #5718] Tue, 11 December 2018 08:36 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
I don't know, Bill - you'll have to tell me how to run it / where it is. I have the Multicomp demo disk (might be derived from the N8VEM demo image or whatever it is called), is it on one of the user areas?

[Updated on: Tue, 11 December 2018 08:36]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5720 is a reply to message #5719] Tue, 11 December 2018 08:59 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
I found ZEXALL and ZEXDOC distributed in YAZE-AG (Yet Another Z80 Emulator). ZEXALL tests all undocumented instructions which T80 VHDL probably won't pass, but it should pass ZEXDOC which tests the documented Z80 instructions. Here is the ZEXDOC.COM that I extracted from YAZE. Just type "zexdoc" at CP/M and wait. It took 26 minutes with a 30MHz Z80, so it should takes 15 minutes or so at 50MHz.
Bill
  • Attachment: zexdoc.zip
    (Size: 4.61KB, Downloaded 33 times)
Re: Superfast Multicomp implementation? [message #5726 is a reply to message #5720] Tue, 11 December 2018 12:12 Go to previous messageGo to next message
wsm is currently offline  wsm
Messages: 137
Registered: February 2017
Location: AB, Canada
Senior Member
Bill: I'm not so sure that ZEXDOC is actually a good benchmark program, especially for FPGA implementations. I was curious to try it on a Z180 even though I know there are a couple of minor differences in DAA, RLD and RRD. I'd forgotten that I'd tried this program quite a LONG time ago with the same result ... it executes invalid Z180 opcodes which cause TRAPs.

Specifically, the first TRAP is in the "aluop a,<ixh,ixl,iyh,iyl>" test which tries to use just the high and low portions of the IX and IY registers: i.e. opcode DD84 which is an undocumented "ADD A,IXh". This may be valid on the Z80, however it TRAPs on the Z180.

I do have the source but it's project #799 on the possible "to do" list. There are quite a few of the tests that need to be commented out: i.e. alu8rx, incxh, incxl, incyh, incyl, ld8ixy etc.

[Updated on: Tue, 11 December 2018 12:13]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5727 is a reply to message #5726] Tue, 11 December 2018 17:21 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 439
Registered: March 2017
Location: New Mexico, USA
Senior Member
I may be way off, but my expectation for the FPGA Z80 is it should pass the ZEXDOC with little or no errors. When turning up the processor clock, we need a instruction set test to make sure the longest path instruction is not broken so a thorough instruction tests, even with known errors, like ZEXDOC is needed.

Bill

PS, ZEXDOC runs reasonably well on Z280. This is the result of Z280 in the 8-bit Z80-compatible mode:

-------------------------------ZEXDOC--on ZZ80RC #2-----------------
b>zexdoc
Z80 instruction exerciser
<adc,sbc> hl,<bc,de,hl,sp>....  OK
add hl,<bc,de,hl,sp>..........  OK
add ix,<bc,de,ix,sp>..........  OK
add iy,<bc,de,iy,sp>..........  OK
aluop a,nn....................  OK
aluop a,<b,c,d,e,h,l,(hl),a>..  OK
aluop a,<ixh,ixl,iyh,iyl>.....  OK
aluop a,(<ix,iy>+1)...........  OK
bit n,(<ix,iy>+1).............  OK
bit n,<b,c,d,e,h,l,(hl),a>....  OK
cpd<r>........................  OK
cpi<r>........................  OK
<daa,cpl,scf,ccf>.............  ERROR **** crc expected:9b4ba675 found:ae5fe733
<inc,dec> a...................  OK
<inc,dec> b...................  OK
<inc,dec> bc..................  OK
<inc,dec> c...................  OK
<inc,dec> d...................  OK
<inc,dec> de..................  OK
<inc,dec> e...................  OK
<inc,dec> h...................  OK
<inc,dec> hl..................  OK
<inc,dec> ix..................  OK
<inc,dec> iy..................  OK
<inc,dec> l...................  OK
<inc,dec> (hl)................  OK
<inc,dec> sp..................  OK
<inc,dec> (<ix,iy>+1).........  OK
<inc,dec> ixh.................  OK
<inc,dec> ixl.................  OK
<inc,dec> iyh.................  OK
<inc,dec> iyl.................  OK
ld <bc,de>,(nnnn).............  OK
ld hl,(nnnn)..................  OK
ld sp,(nnnn)..................  OK
ld <ix,iy>,(nnnn).............  OK
ld (nnnn),<bc,de>.............  OK
ld (nnnn),hl..................  OK
ld (nnnn),sp..................  OK
ld (nnnn),<ix,iy>.............  OK
ld <bc,de,hl,sp>,nnnn.........  OK
ld <ix,iy>,nnnn...............  OK
ld a,<(bc),(de)>..............  OK
ld <b,c,d,e,h,l,(hl),a>,nn....  OK
ld (<ix,iy>+1),nn.............  OK
ld <b,c,d,e>,(<ix,iy>+1)......  OK
ld <h,l>,(<ix,iy>+1)..........  OK
ld a,(<ix,iy>+1)..............  OK
ld <ixh,ixl,iyh,iyl>,nn.......  OK
ld <bcdehla>,<bcdehla>........  OK
ld <bcdexya>,<bcdexya>........  ERROR **** crc expected:478ba36b found:96e927a2
ld a,(nnnn) / ld (nnnn),a.....  OK
ldd<r> (1)....................  OK
ldd<r> (2)....................  OK
ldi<r> (1)....................  OK
ldi<r> (2)....................  OK
neg...........................  OK
<rrd,rld>.....................  OK
<rlca,rrca,rla,rra>...........  OK
shf/rot (<ix,iy>+1)...........  ERROR **** crc expected:713acd81 found:dfbbe74b
shf/rot <b,c,d,e,h,l,(hl),a>..  ERROR **** crc expected:eb604d58 found:43e7b72d
<set,res> n,<bcdehl(hl)a>.....  OK
<set,res> n,(<ix,iy>+1).......  OK
ld (<ix,iy>+1),<b,c,d,e>......  OK
ld (<ix,iy>+1),<h,l>..........  OK
ld (<ix,iy>+1),a..............  OK
ld (<bc,de>),a................  OK
Tests complete

[Updated on: Tue, 11 December 2018 17:23]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5728 is a reply to message #5727] Tue, 11 December 2018 21:24 Go to previous messageGo to next message
wsm is currently offline  wsm
Messages: 137
Registered: February 2017
Location: AB, Canada
Senior Member
I just wanted to point out that although the user is led to believe that ZEXDOC only tests documented instructions, it actually tests undocumented instructions as well. As such, I find the distinction between ZEXDOC and ZEXALL very misleading.

I agree that an FPGA exerciser should test as many of the instruction permutations as is practical but I'm not going to debate whether it should emulate the original core for undocumented instructions. My approach is very simple ... undocumented means unsupported and not valid for the programmer to use. Just because an undocumented instruction works on Zilog's Z80 silicon, there is absolutely no guarantee that it will work on other Zilog (or the many other manufacturer's) devices that are documented as "code compatible with Z80". Unlike the Z80, the Z180 TRAPs invalid opcodes which I find to be a useful aid in debugging and checking for compatibility.
Re: Superfast Multicomp implementation? [message #5729 is a reply to message #5728] Tue, 11 December 2018 23:13 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
ZEXDOC ran in just under 16 minutes and passed all tests on the 50Mhz Multicomp.

When I have finished sorting the RTC out I'll time it properly.

[Edit: 15 minutes 30 seconds to be more precise..]

[Updated on: Fri, 14 December 2018 04:36]

Report message to a moderator

Re: Superfast Multicomp implementation? [message #5777 is a reply to message #5729] Wed, 19 December 2018 04:02 Go to previous messageGo to next message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
I've discovered why it won't clock past 50Mhz. The TERMINAL component cannot handle the speed! So now, I am testing by activating the serial port.

Build of vi.com:

CPU 60Mhz, SD 15Mhz - 52 seconds
CPU 60, SD 30 - 48 seconds
CPU 60, SD 40 - 48 seconds (CPU is not keeping up with the SD card)
CPU 60, SD 50 - doesn't boot CP/M
CPU 65, SD 25 - (can't setup PLL with 65/30) - no boot
CPU 70, SD 25 - (can't setup PLL with 70/30) - no boot
CPU 75, SD 20 - no boot

In each instance of boot failure, the TERMINAL screen shows corruption. Recall that it always prints the prompt on there: "Press [SPACE] to activate console", so perhaps this is causing the Multicomp to crash once we exceed its maximum operating speed. Let's try to comment the TERMINAL out (from Microcomputer.vhd) and see if serial-only operation allows a boost:

CPU 65, SD 25 - no boot
CPU 75, SD 25 - no boot
CPU 70, SD 33 - no boot

Hmm. This does work at the lower speeds so I assume it's not failing because I've not removed the TERMINAL component properly.

For now, then, I think it points to a maximum clock speed of 60/40 for serial only, or 50/50 with the TERMINAL component. Given 50/50 occasionally fails to boot, and that there is no difference between 50/50 and 50/40, I will stick with 50/40 until the TERMINAL component's performance can be improved.
Re: Superfast Multicomp implementation? [message #5778 is a reply to message #5777] Wed, 19 December 2018 06:03 Go to previous messageGo to previous message
jonb is currently offline  jonb
Messages: 91
Registered: August 2016
Location: UK
Member
..and now, after all the experimentation, I can't boot CP/M at all... I wonder what has gone wrong now? Rolling Eyes

Edit: Not to worry. During testing the boot track must have got corrupted somehow. Efforts to restore it failed, until I realised that it's necessary to upload CPM22.HEX before CBIOS128.HEX in the monitor, as there is an overlap (where the CBIOS vector table is).

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

Report message to a moderator

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


Current Time: Tue Jan 21 10:21:33 PST 2020

Total time taken to generate the page: 0.04611 seconds