WTB: Heathkit ID-4801 EPROM Programmer - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: WTB: Heathkit ID-4801 EPROM Programmer
Charlie Gibbs:

Quoted text here. Click to load it

LOL. It actually come from a joke about a safari.

The participants bragged about how many lions, gazelles etc. they killed,
while one of them only got some Noplis.

- What are Noplis? - asked another hunter.
- Dunno, sort of apes that, when aimed at, scream "noplis, noplis".

Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it

"Don't step in the huzzanga!"

;-)
Rich



Re: WTB: Heathkit ID-4801 EPROM Programmer
Rich Grise:

Quoted text here. Click to load it

What's that? Tell me, tell me!

Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it

Some missionary was speechifying in some village, and at every salient
point, the crowd would chant, "Huzzanga! Huzzanga!"

Of course, he assumed they were cheering hin on. (compare "Hooray!")

Well, after his speech, the chieftan takes him on a tour of the village,
and says, "Careful, don't step in the huzzanga!"

Cheers!
Rich



Re: WTB: Heathkit ID-4801 EPROM Programmer
Rich Grise:

Quoted text here. Click to load it

Good! I was expecting the stuff "either huzzanga or else die".

Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it

Nah, that's the Foo bird. ;-)

Cheers!
Rich



Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it

Rubbish, unless you are doing bare-metal programming on the PC (and no
sane person would do that).

Quoted text here. Click to load it

No, it will not work - USB 1.1 (as used by most FTDI chips) runs on a 1
ms cycle.  Even with USB 2.0 (as used by some faster FTDI chips) runs on
a 0.1 ms cycle.  This means that any time you need to read a port then
set some outputs based on the inputs, you have an absolute minimum of
0.2 ms latency - three orders of magnitude too high for an eprom
emulator.  For proper emulation of the signal sequencing, you would need
several read-write cycles making it even worse.

Quoted text here. Click to load it

That's almost right - but drop the "PIC".  They are horrible devices,
and too slow here.  Even using a decent small micro like an AVR, you
couldn't emulate an eeprom at more than about 1-2 MHz.  And if you have
a chip that is fast enough, it is difficult to get consistent timings.

A much better idea is to use a small programmable logic device with a
ram chip and a USB connection.  You don't need much - a 128 macrocell
PLD would be enough if you use an FTDI chip for the usb connection.  Or
you could buy one of FTDI's modules with a Cylone FPGA - it's overkill,
but easily available and ready-made.

Re: WTB: Heathkit ID-4801 EPROM Programmer
On Wed, 27 Oct 2010 11:33:59 +0200

Quoted text here. Click to load it

    Which if you look elsethread you will see is exactly what I had in
mind - I never suggested this was a sane thing to do (quite the opposite),
just that it was probably possible.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.
Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it
Not in Windows, you won't. Maybe DOS, or Linux in single-user mode.

Good Luck!
Rich


Re: WTB: Heathkit ID-4801 EPROM Programmer
On Tue, 26 Oct 2010 11:45:36 -0700

Quoted text here. Click to load it

    Without an OS at all was what I had in mind - DOS come close enough
though.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.
Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it

linux single user mode is just an administrative convenience.
so probably not.

dos maybe, if the DRAM refresh, clock interrupt, etc...  
don't cause problems.

--
ɹǝpun uʍop ɯoɹɟ sƃuıʇǝǝɹ⅁


Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it

DRAM refresh is only an issue on a 8086,8088, 80186 or 80286.  Modern
systems don't involve the interrupt subsystem in DRAM operations (other
than to signal corrected events (such as Intel's CMCI or AMD's equivalent).

There are several modern real-time capable code bases such as VxWorks
or WindRiver that can be licensed and would support EPROM emulation
on an x86 based system.

scott

Re: WTB: Heathkit ID-4801 EPROM Programmer




Quoted text here. Click to load it

Huh? DRAM refresh is the issue whenever a DRAM is involved.

Quoted text here. Click to load it

Neither PC/XT or PC/AT did. On original PCs, the refresh was
accomplished by DMA channel. In our days, refresh is the function of the
north bridge and it indeed creates random access latencies.

Quoted text here. Click to load it

WTF are you talking about?

Quoted text here. Click to load it

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com


Re: WTB: Heathkit ID-4801 EPROM Programmer
Quoted text here. Click to load it

DRAM refresh is completely handled and scheduled by the integrated
memory controller (Opteron, Nehalem, Sandybridge) or by the northbridge
chipset (Pentium family, Xeon prior to Nehalem).

It has had no impact on system execution latency for decades.


Quoted text here. Click to load it

If the IMC detects corrected ECC (single or double-bit) errors beyond
a programmable threshhold, it will generate a CMCI (corrected Machine Check
Interrupt) to the operating software.    AMD has an equivelent operation
(and a nice bit in the IMC that injects a corrected single-bit error on
every memory reference for testing).

The point is, that DRAM refresh has not had a latency impact on running
modern x86 processors for two decades.

scott

Re: WTB: Heathkit ID-4801 EPROM Programmer
On 30 Oct 2010 03:23:15 GMT

Quoted text here. Click to load it

    I don't think it ever needed to have an impact on system latency,
certainly it never did on any of the Z80 systems I built.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.
Re: WTB: Heathkit ID-4801 EPROM Programmer
Ahem A Rivet's Shot:

Quoted text here. Click to load it

That's why they've built multiple-pipelines processors.

The refresh, on the Z80, was done right after the instruction fetch, while
the instruction decoder was busy figuring out what to do.
In that time the bus would have been idle anyway, that's why Federico used
it for DRAM refresh.

Re: WTB: Heathkit ID-4801 EPROM Programmer



Quoted text here. Click to load it

Of course. If DRAM is twice as fast as processor, then refresh cycles
could be free. But when DRAM is 100 times slower, the situation is a bit
different.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com



Re: WTB: Heathkit ID-4801 EPROM Programmer
Vladimir Vassilevsky:

Quoted text here. Click to load it

Well, to be precise, that was not the case. As a matter of fact the M1
(fetch+refresh) was the most critical, for the memories. At the time a 4MHz
CPU and the RAM were equally fast.

Quoted text here. Click to load it

It's what I was trying to explain to a guy in another NG. With a Z80 and a
modern static RAM you can easily write on video RAM while doing screen
refresh.

Quoted text here. Click to load it

Of course. I was about to answer also to Scott, but I thought that it was
your discussion. ;-)

To be precise, the RAM is not slower, it's almost ten times faster than
then. It's the processor that is some thousands times faster.

Re: WTB: Heathkit ID-4801 EPROM Programmer



Quoted text here. Click to load it

The DRAM controller has a queue of requests to the DRAM from all bus
masters; refresh controller is one of them. Each request is assigned
priority; this priority depends on the variety of things such as what
subsystem originated the request, how urgent is this request, how long
the request was pending, if the request falls into the currently opened
row, etc. etc. etc. The request that wins the arbitration gets the
access to DRAM.

It is quite possible that the DRAM controller queue will be empty at
instant as the cores are running from their caches and all other masters
are in idle; so the refresh request will be serviced transparently to
the other operation. However, the system latency is determined by the
worst case scenario rather then the best case. As such, refresh is one
of the factors that have dramatic impact on the system latency; although
the averaged effect of refresh on the system speed is negligible.

(Yes, I do work with DDR/DDR2 and their controllers).

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com









Re: WTB: Heathkit ID-4801 EPROM Programmer
Vladimir Vassilevsky:

Quoted text here. Click to load it

Gosh! And all those tasks are done in hardware, I suppose.
Is the achitecture similar to a MMU? Does it have a sort of TLB?

Site Timeline