I got my first 5MHz NSC800 adapter board back today. I have one built and
installed in an M100 dedicated to CP/M. It worked as planned.
The only mods to the M100 were-
1. Remove 80c85 and install socket
2. Install Z80 version of M100 OS in 100nsec eprom
3. And of course RECXPM for ram.
I
Hi I see where you are going but in this case no. The cpu has a fixed time
period to get a response on the bus. As you go faster the device simply
cant put the correct data on the bus in time. Waiting in software would
amount to asking the device repeatedly...but every response is incorrect.
On Sun, Nov 15, 2020 at 12:48 PM Stephen Adolph
wrote:
> good question. In fact it is hardware. the response time of those
> drivers is pretty slow. seems like the first thing that happens is the
> pixels start to get distorted a bit.
>
And that's because of the higher clock frequency?
>
Yes, the stock CPU can run at 5MHz at least. I haven't tested it on my
latest incarnation of test setup so I don't have fine resolution on when it
dies.
I could see how much more is in the tank for a stock cpu.
I actually don't think it is worth it to use the Tundra 8MHz chip because
the rest of
On Nov 15, 2020, at 8:54 AM, Stephen Adolph wrote:
> @5MHZ, any 80C85 and any NSC800 can work
I recall you saying you were experimenting using an 8MHz binned 80C85. I'm
curious if early in the process you tried any experiments with a stock CPU --
that is, trying to produce the most
John,
good question. In fact it is hardware. the response time of those drivers
is pretty slow. seems like the first thing that happens is the pixels
start to get distorted a bit. And then if you go faster, the laptop
freezes at one specific location - in a loop where the LCD driver status is
On Sun, Nov 15, 2020 at 8:54 AM Stephen Adolph wrote:
>
> 2) as some speed, the LCD can't keep up so you get missing pixels
>
>>
>>>
Curious if that's a hardware or software problem.
As in, is there some dependency in the code on a slower speed that has
always been there. Or is this a
I have some more results. My 74HC4046 PLL worked pretty well to generate a
fine tune clock rate. It is a bit jittery, so not ideal.
As a result this data is probably worse than it really is.
These results are using hardware with
1) 150nsec EPROM ROM
2) 100 nsec SRAM
3) M2 upgraded buffer
keeping my experiment rolling ;)
I just received the "high speed rated" NSC800, supporting 4MHz.
Now, I did successfully run the 2.5 MHz rated part at 5MHz, so I will be
interested to see if the 4MHz part is really any faster in the M100.
as usual, I will report back.
On Fri, Nov 6, 2020 at
To continue the exploration on overclock,
I have assembled a proper clock synthesizer which can generate any clock
from 2.5M to 10M. It uses a 74HC4046 PLL chip, a 10 divider and a 250kHz
to 1MHz source clock.
So this will let me finely tweak clock period to try and estimate safe
overclock.
One more thought here
I wish there was a deterministic way to figure out how much overclocking is
safe vs prone to bus errors or otherwise.
It is a statistical thing, and I guess if I had a very finely tunable
clock, one could try to write some test software that reported "time" over
and
The ic has internal biasing resistors so I’ve just used hiz on outputs to drive
it in all 3 states
But I will concede on the current drain. If you can find the correct
oscillator speed, the cpld only option is easiest. If you write the verilog
such that clock speed changes on the falling
Great idea to do clock stretching!
That clock multiplier is pretty neat, but it will absorb 12-20mA. And you
would need a resistor network to control it.
Using a 98.304 MHz oscillator @5mA seems like a better approach + no
resistors.
On 11/1/2020 8:18 PM, Stephen Adolph wrote:
You have to multiply by 2. The input frequency to the processor is 2x
the cpu speed
Stock is 4.9152 MHz.
So yes , but x2.. implication is a pretty fast cpld. I think the xcr
family at 7ns may just do it.
To cut down on required CPU speed,
You have to multiply by 2. The input frequency to the processor is 2x the
cpu speed
Stock is 4.9152 MHz.
So yes , but x2.. implication is a pretty fast cpld. I think the xcr
family at 7ns may just do it.
On Sunday, November 1, 2020, RETRO Innovations
wrote:
> On 11/1/2020 6:19 PM,
On 11/1/2020 6:19 PM, Stephen Adolph wrote:
It would be convenient to stick to multiples of 2.4576MHz so that it
is an easy divisor to create the system clock of 2.4576 MHz.
14.7456 gives gives divisors of
6,4,3,2 for frequencies of:
2.4576 3.6864 4.9152 7.3728
73.728MHz gives divisors
It would be convenient to stick to multiples of 2.4576MHz so that it is an
easy divisor to create the system clock of 2.4576 MHz.
On Sun, Nov 1, 2020 at 6:33 PM Stephen Adolph wrote:
> Yep possible for sure. Worth more investigation.
>
>
>
>
> On Sun, Nov 1, 2020 at 4:25 PM RETRO
Yep possible for sure. Worth more investigation.
On Sun, Nov 1, 2020 at 4:25 PM RETRO Innovations
wrote:
> On 11/1/2020 12:52 PM, Philip Avery wrote:
> > Could Turbo mode be software selectable? Just curious as if you were
> > to enter MVT100 (or VT-100 output with CP/M), you wouldn't be
>
On 11/1/2020 12:52 PM, Philip Avery wrote:
Could Turbo mode be software selectable? Just curious as if you were
to enter MVT100 (or VT-100 output with CP/M), you wouldn't be
constrained by internal M100 LCD.
I was thinking the same thing. A small 44 pin CPLD under the socket,
attached to the
Could Turbo mode be software selectable? Just curious as if you were to
enter MVT100 (or VT-100 output with CP/M), you wouldn't be constrained
by internal M100 LCD.
Philip
On 2/11/2020 12:44 am, Stephen Adolph wrote:
Final story on 8MHz (well final for now!).
Actually, the
Depending on the programmer, you could use an adapter cable from the programmer
to a clip to go directly on the chip. Mike would probably have a more
definative answer. The type of EPROM/EEPROM soldered in could matter as well.
Nov 1, 2020 9:52:58 AM Brian White :
> Some kind of borked re-send
Some kind of borked re-send of a draft. Didn't I already send a proper
version of that?
Anyway disregard the last bit. I was starting to wonder if Mike's board
might work as it's own programming adapter because it includes both the old
and new pinouts. But that was silly and won't work because
Teeprom is for the option rom.
FlexROM_100 or FlexROM_102 is the main rom.
Well really just the 100.
No one really needs the 102 version because for 102 you can just use a
plain 27C256 which is a lot simpler. Just for 102 you want to get some
chipquick or fastchip desoldering alloy to get the
I see 2 reasonable options. Wondering what interest there would be /
reactions to these 2 options.
Option 1. 80C85/4MHz. 1.66x speed increase
- supports classic M100 use and CP/M
- compatible with stock CPU, stock RAM, stock Main ROM, and existing
option ROMs
- CPU adapter board
Final story on 8MHz (well final for now!).
Actually, the processor/ram/keyboard all work at 8MHz. Only one thing I
can see, and it is pretty important, doesn't. The LCD.
The driver chips have to communicate with the CPU, and they are just too
slow to get their data on the bus in time.
So, I
Teeprom is for the option rom.
FlexROM_100 or FlexROM_102 is the main rom.
Well really just the 100.
No one really needs the 102 version because for 102 you can just use a
plain 27C256 which is a lot simpler. Just for 102 you want to get some
chipquick or fastchip desoldering alloy to get
On Sat, Oct 31, 2020 at 5:52 PM Joe Grubbs wrote:
> Aww yeah! I'm liking where this is going. Will the sluggish original ROM
> handle 8Mhz+?
>
No, for sure not. Right now I have a 120nsec EEPROM in the socket and it
supports 6.2 MHz.
If I simply place the original ROM back in - no go.
But the
Aww yeah! I'm liking where this is going. Will the sluggish original ROM handle
8Mhz+?
From: M100 on behalf of Stephen Adolph
Sent: Saturday, October 31, 2020 5:23 PM
To: m...@bitchin100.com
Subject: Re: [M100] M100 overclock
I've had a bit of spare time
I've had a bit of spare time to fiddle.
I now have 6 MHz running nicely (actually 6.2MHz). Screen issue resolved
(was a different problem). Also serial port is working. TSDOS at 6MHz
is.. fast!
I won't go into the details yet, as I have poked around a bit here and a
bit there. When I'll do a
while stewing over how to speed up the data bus, I had the idea to piggy
back 2 74HC245 bi-di drivers.The nice thing about this hack is that you can
just solder on another part... easy.
This combination is the fastest, and still low power!
In this config I can run at *6MHz*, but the LCD starts to
Well, it is quite noticeable, still an M100 though. I would say the
responsiveness is good.
Harder on the batteries though.
Since I use M100 virtually always on external power, a turbo machine could
be ok.
I'm going to try and get the fastest M2 replacement I can, and see if it
can be pushed
On Oct 29, 2020, at 3:12 PM, Stephen Adolph wrote:
> update for the hardware geeks (I may be the only one?)
My education was on the hardware side of things, though I've never put it into
practice. It is interesting to hear your regular reports of your various
experiments. Please keep it up!
Hi Stephen,
Updates are always welcome - You are not the only one :-)
Kindest regards,
Doug Jackson
em: d...@doughq.com
ph: 0414 986878
Check out my awesome clocks at www.dougswordclocks.com
Follow my amateur radio adventures at vk1zdj.net
update for the hardware geeks (I may be the only one?)
The first bottleneck is the data bus.
Swapping M2 for a faster 74LS245 yields *5MHz.* Of course this is bad for
current, so maybe there is a better CMOS part out there.
continued tweaking...
On Thu, Oct 29, 2020 at 12:52 PM Stephen Adolph
I have an early result on overclocking the M100.
In my testbed I have a stock M100, with a couple of changes.
1) I have a socket on the 80C85
2) the standard 2.45MHz clock is generated and fed to the system so that
stays constant
3) I feed the CPU with a separate clock that can range from 2.5 to
35 matches
Mail list logo
