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 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
jonb wrote on Fri, 30 November 2018 05:30Got 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
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 #5657 is a reply to message #5656] |
Fri, 30 November 2018 07:13 |
JonB
Messages: 92 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 304 times)
-
Attachment: SUBMIT.zip
(Size: 1.35KB, Downloaded 302 times)
[Updated on: Fri, 30 November 2018 07:18] Report message to a moderator
|
|
|
|
|
Re: Superfast Multicomp implementation? [message #5662 is a reply to message #5660] |
Fri, 30 November 2018 09:02 |
JonB
Messages: 92 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 #5670 is a reply to message #5669] |
Sun, 02 December 2018 02:35 |
JonB
Messages: 92 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 #5672 is a reply to message #5671] |
Sun, 02 December 2018 05:32 |
nealcrook
Messages: 127 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 #5691 is a reply to message #5680] |
Thu, 06 December 2018 03:22 |
JonB
Messages: 92 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 228 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 |
b1ackmai1er
Messages: 396 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 |
JonB
Messages: 92 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 #5696 is a reply to message #5695] |
Thu, 06 December 2018 08:20 |
JonB
Messages: 92 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 #5701 is a reply to message #5700] |
Thu, 06 December 2018 13:24 |
JonB
Messages: 92 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 |
JonB
Messages: 92 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
|
|
|
|
|
Re: Superfast Multicomp implementation? [message #5717 is a reply to message #5716] |
Tue, 11 December 2018 07:18 |
JonB
Messages: 92 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
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 #5726 is a reply to message #5720] |
Tue, 11 December 2018 12:12 |
wsm
Messages: 223 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 |
plasmo
Messages: 866 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 #5777 is a reply to message #5729] |
Wed, 19 December 2018 04:02 |
JonB
Messages: 92 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 |
JonB
Messages: 92 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?
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
|
|
|
Current Time: Fri Mar 29 00:38:15 PDT 2024
Total time taken to generate the page: 0.50151 seconds
|