>Tim,
>
>I should have qualified that as common residential and business circuits.
>Sure it's possible to go to 60A, how many houses nomially have that?
>(don't include mine).
>
>Allison
>
I have a few 50A 120 and 240v. Then to I have a 400A house service that I
subfed 200A to my office / shop and then to the shed where the welder is.
I even put a 100A panel on the wall behind the row of 7 6 foot racks for the
test beds. It was cheaper and easier than putting all those Hubbell's on
the wall.
Dan
To help reduce the US power confusion I just hand scratched a US single
phase power configuration from the pole transformer into the first breaker
panel. All panels after the first one are not allowed to have the Neutral
and Ground tied together. (Sub feed panels)
Please ignore the horrible hand drawing I just want people to be safe.
ftp://zane.brouhaha.com/pub/dan/power.gif
Dan
OK, so it's not the holy grail (apple lisa) , but it's close. Picked up a
complete Hero1 with speech synth and arm in his own custom carrying box. it
came complete with charger, cables, all schematics and manuals and some dos
based compiler programs to write apps that can be downloaded to the robot via
serial link. Also got a data book on all motorola chips and some robotics
study courses as well as lots of handwritten notes by the original owner.
Unfortunately, he doesnt work right. I think his motor drive may have to be
rebuilt and although he did say "okay" once, his digital display is scrambled
and he wont initialise. Gel cell batteries will have to be replaced since
he's been sitting for at least 5 years. Will be a fun project and will get
plenty of space on the upcoming computer museum website.
I'm no expert on Roman numerals, but I recently saw a movie released in MCMXLIX. Now, we know what the MCM means, but I submit that the intention of chiseling as little stone as possible, the romans avoided the use of 4 successive numerals by use of bi-quinary counting. However, the use of IX for 9 as opposed to VIV, as in the MCM above, is a bit ambigous. I'm not planning any trips to the former Roman Empire, so I doubt I'll do better than trusting the conclusion reached in this forum. Does anybody have an authoritative reference?
Dick
-----Original Message-----
From: Hans Franke <Hans.Franke(a)mch20.sbs.de>
To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu>
Date: Tuesday, April 20, 1999 3:10 PM
Subject: Re: Program Challenge (was Re: z80 timing... 6502 timing)
>
>> > > Convert a binary value to Roman, using ASCII characters (or
>> > > the native character set if applicable) into a string
>> > > with a termination character (if ASCII, use the NUL (0)
>> > > character).
>> > Is a length terminated record valid ?
>
>> Hmmmm ... I might be inclinded to say yes, but is there any reason it
>> can't be NUL terminated (or terminated with the appropriate termination
>> character for the character set)?
>
>Just since it is the usual way within the OS I'm trying to code.
>NUL is like any other caracter valid within a string. Also, it
>gieve me an disadvantage - instead of just adding '\0' I have
>to calculate the string.
>
>> > > The valid Roman characters used are IVXLCDM
>> > Is Space valid ? Romans did include them at will.
>> I did not know that, but for this program no, spaces are not allowed.
>
>Ok.
>
>> > > > There are a few details which have been left out of the specification for
>> > > > this task.
>> > > > Does it require input validation?
>> > > I think I specified that. The valid range of Roman numerals is 1 through
>> > > 3,999 inclusive. The routine does have to check that and construct a
>> > > special string ( "*" ) if the input is not in that range.
>> > > > Is the binary input pure binary, or is it BCD?
>> > > Okay, that might be a valid point, but it's pure binary, not BCD.
>
>> > Fine, you stated max input 3999, but to be checked, and you
>> > stated binary, but in what format ? Half Word (16 Bit),
>> > Word (32) or Double Word (64) ?
>
>> Uh, I was unaware that halfwords had a specific size (on the DEC Alpha, a
>> half word would be 32 bits in size).
>
>Like Words, they are just machine dependant ... in a given 32 Bit CPU
>a halfword is just 16 - so whats the input ? (in fact, I'll assume 32 Bit)
>
>> > To be transfered at a given location, or via a pointer,
>> > or via register (attention, might again be processor specific).
>
>> Appropriate to the CPU or the situation. Obviously, a 6502 can't pass it
>> in a single register, but there are other options. That's why I didn't
>> specify how to pass the data in.
>
>:))) And why specifying a '\0' byte ?
>
>> > > I liked Sam's suggestion of ``printing to memory'' as a way to avoid the
>> > > complications of I/O in this, and if I didn't make this clear that the
>> > > conversion was to be stored in memory, I'm sorry.
>>
>> > Output, to a given location (pointer) or static buffer ?
>> > Check for buffer length or asumption of an buffer, always big
>> > enough ? (if you check the binary number you also have to check
>> > the buffer (if given).)
>
>> Again, it's up to the programmer. But be prepared to justify your answers
>> 8-)
>
>:))
>
>> -spc (Welcome to the world of programming 8-)
>
>All simple, all the same, isn't it ?
>
>And again, more questions:
>If I'm right at Megans description, she just include the next lower
>digit when it comes to these subtraction rules, and your Algo seams
>to be weak at the same point. Let me give an example:
>
>49 would be normaly coded as IL (always remember, it was kind of a
>system to reduce writing as much as possible - there are even examples
>where the number 248 is written CIIL) while Megan seams to code it as
>XXXXIX - basicly wrong - or did I miss something ? I'm not realy
>what one can call a DEC-Geek.
>
>So do we only have to supporte the one-less rule, or the rule
>of one subtraction numeral - or the full possibility with the
>goal to reduce writing to a max ?
>
>Gruss
>H.
>
>Oh, BTW: this contest is exacty into the direction where we didn't
>want to go - we are comparing algorythms and not CPUs - for a more
>CPU dependant contest we need to fix the algo to use, so the difference
>will reflect the differences in processor design and not into algo
>design (of course there's more sex appeal in the my-algo-is-bether-
>than-yours, than in the my-(what-ever-algo)-implementation-is-better).
>
>So I still go for the idea of implementing one algo as good as possible
>for the different CPUs - more on Friday (I'm not full time available
>until then).
>
>
>
>--
>Stimm gegen SPAM: http://www.politik-digital.de/spam/de/
>Vote against SPAM: http://www.politik-digital.de/spam/en/
>Votez contre le SPAM: http://www.politik-digital.de/spam/fr/
>Ich denke, also bin ich, also gut
>HRK
<Perhaps soft iron #2 washers would be a better choice. The local hardware
Same material as the nuts. A higer carbon steel (more remnant magnetizem)
may work but you really want small to keep the drive resonable.
Allison
>
> Realy 234V (strange) and 180 degree ? Where do you know ? By definition ?
> Just remember, if you tap between 2 phases of a 3~ signal you still get
> a perfect sinus and you can't decide if it is a single phase or part of
> a 3 phase signal. Ok, I'm always learning new things on this earth :9
> The numbers just saemed to fit well.
>
It's 230, 231, whatever it takes (from the movie "Mister Mom").
I'm sure the power company has a legal obligation to keep the voltage
within a certain range of values. Although, I don't know exactly what that
range is. I think 117 is probably the optimal value for each of the legs
giving 234 for the total. I've heard it referred to as 110, 115, 117, and
120. Since the actual voltage varies any of these could be correct.
Since it is a simple transformer, the phases are 180 degrees out of phase
(by definition). That's assuming a balanced resistive load. Of course, that
could change under a heavy inductive or capacitive load but, that's an
extreme and won't normally present a problem.
Steve Robertson - <steverob(a)hotoffice.com>
There are a few details which have been left out of the specification for
this task.
Does it require input validation?
Is the binary input pure binary, or is it BCD?
Shouldn't it go both ways, i.e. shouldn't we also have to convert ROMAN to
BINARY as well as BINARY to ROMAN?
What about the console I/O routine? Shouldn't there be some definition of
how it's to be used? Should it be a call with the I/O character simply held
in a register before/after the call?
How much memory is used can be defined in two ways. (a) the number of
bytes, and (b) how much contiguous memory must be present in order to allow
the code to be implemented. It requires 200 bytes of RAM is not a valid
statement if that RAM has to be scattered over a 32-KByte range. If your
claim is that your code runs in 200 bytes of memory, it must be runnable on
a computer having only 200 bytes of memory. If you can't figure out how to
build a 200-byte RAM, then perhaps it might be more appropriate to suggest
it requires only 256 bytes of RAM, which you can buy.
Was the processor in question available in 1983? As I recall, the 6809 was,
but there are some which weren't.
Now, for the more subjective aspects of the comparison, how was the code
initially generated? How long did it take to code the problem? How long
to debug it?
How is the 6809E relevant to the timing of the Z-80 and 6502?
These issues should be resolved, I think, before everyone takes off.
Dick
-----Original Message-----
From: Sean 'Captain Napalm' Conner <spc(a)armigeron.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, April 18, 1999 1:28 AM
Subject: Re: Program Challenge (was Re: z80 timing... 6502 timing)
>
> My entry uses the MC6809E as used in the Color Computer Line from Tandy.
>My general approach to this (as well as programming in general) is to avoid
>the use of logic statements (comparisons/branches) and trying to use all
the
>registers to their best possible use.
>
> Static memory usage: 163 bytes
> Dynamic memory: 16 bytes
> Stack memory: 12 bytes
>
> Minimum Cycles: 21
> Maximum Cycles: 687
> One digit:* 144
>
> *Due to implementation, this can be 1, 10, 100 or 1,000.
>
> Code ROMable: Yes
> Data ROMable: Yes
> Code is Re-entrant: Yes
> Data is Re-entrant:* Yes
> Undefined Opcodes: No
> Undefined Behavior: No
>
> *Does a separate copy of static memory need to be created
> for each re-entrant copy? If this answer is `no', then
> the data is re-entrant.
>
> The main process is set up to avoid complicated logic, which leads to
both
>speed loss and size bloat. To this end, I have a jump table for each digit
>to print (PTAB). The digits to be printed are stored in TABLE in decending
>order, since that's the way I calculate the number (from largest to
>smallest). I classifed the Roman numbers into two classes, ones and fives.
>The `ones' class contains I, X, C and M. The `fives' class contains V, L
>and D. There is another class, called `tens' which is a subclass from
>`ones' (X, C and M). TABLE is set up such that for any grouping, [the
>register] X points to the `ones' character, the previous character is the
>`fives' character, and the one previous to that is the `tens' character.
>The routines pointed to by PTAB should be relatively straight forward from
>there.
>
> The only other tricky part comes to actually calculating the values to
>print. ROMSUB repeatedly subtracts a value from the value we passed in,
>keeping track of the number of times we do a subtract. This value to
>subtract is stored inline of the code and is pulled off from the stack.
The
>actual return is stored on the stack, and is done by `JMP [1,S]' (where the
>top of the stack contains the count).
>
> The calls to ROMSUB occur from RM1000, RM100, RM10 and RM1, and to get
>there, we first store the address of RM1000 onto the stack, and in the main
>loop, the first line of code `JSR [,S] calls RM1000. This returns with the
>count on the top of the stack (and the address to RM1000 is still there)
>where we then convert it to a Roman digit. Then we update the address to
>RM1000 by 4, which then points it to RM100. We keep doing this, calling
>RM10 and RM1. The last adjustment lands us in RMEXIT, which cleans up the
>stack and returns to the calling program.
>
>**************************************************
>* ROMAN CONVERT BINARY VALUE TO ROMAN NUMERALS
>*
>*ENTRY D VALUE TO CONVERT
>* Y DESTINATION OF AT MOST 16 BYTES
>*EXIT D DESTROYED
>* Y PRESERVED
>* ALL OTHERS SAVED EXCEPT CC
>***************************************************
>
>ROMAN CMPD #3999 CHECK RANGES
> BGT ROMERR
> CMPD #0
> BLE ROMERR
> PSHS X,Y,U
> LDX #RM1000
> PSHS X
> LDX #TABLE
>
>ROM10 JSR [,S]
> PSHS D
> LDB 2,S
> BEQ ROM20
> ADDB 2,S
> SUBB #2 TIME SHORTER THAN DECB/DECB
> DECB INDEX INTO JUMP TABLE
> LDU #PTAB
> JSR [B,U]
>ROM20 PULS D
> LEAS 3,S REMOVE COUNT AND RETURN ADDRESS
> LDU ,S ADJUST FOR NEXT ROUTINE
> LEAU 4,U
> STU ,S
> LEAX 2,X INCREMENT TO NEXT CHARACTER
> BRA ROM10 CONTINUE
>
>ROMERR LDD #$2A00
> STD ,Y MARK ERROR AND END OF STRING
> RTS
>
>RM1000 BSR ROMSUB
> FDB 1000
>RM100 BSR ROMSUB
> FDB 100
>RM10 BSR ROMSUB
> FDB 10
>RM1 BSR ROMSUB
> FDB 1
>RMEXIT LEAS 4,S
> CLR ,Y
> PULS X,Y,U,PC
>
>ROMSUB PULS U
> CLR ,-S
>
>RS10 CMPD ,U
> BLO RS20
> SUBD ,U
> INC ,S
> BRA RS10
>RS20 JMP [1,S] RETURN TO CALLER OF CALLER TO ROMSUB
>
>TABLE FCC 'MDCLXVI'
>
>PTAB FDB P1
> FDB P2
> FDB P3
> FDB P4
> FDB P5
> FDB P6
> FDB P7
> FDB P8
> FDB P9
>
>***********************************************
>* FOLLOWING ROUTINES HAVE THE FOLLOWING
>* ENTRY B OFFSET INTO JUMP TABLE
>* U JUMP TABLE
>* X TABLE
>* Y STRING TO STORE INTO
>* EXIT A DESTORYED
>* B DESTROYED
>**********************************************
>
>P3 LDA ,X LOAD FROM 1 TABLE
> STA ,Y+ STORE CHARACTER
>P2 LDA ,X
> STA ,Y+
>P1 LDA ,X
> STA ,Y+
> RTS
>
>P4 LDA ,X
> STA ,Y+
>P5 LDA -1,X LOAD FROM 5 TABLE
> STA ,Y+
> RTS
>
>P6
>P7
>P8 LDA -1,X
> STA ,Y+
> SUBB #10
> JMP [B,U]
>
>P9 LDA ,X
> STA ,Y+
> LDA -2,X LOAD FROM 10 TABLE
> STA ,Y+
> RTS
>
>***********************************************
>
> -spc (Eat and Enjoy ... )
>
<I've never tried it, but I remember reading in some DIY computer book
<from the 1960s that those anti-parasitic beads didn't work as core memory
<cores. I suppose you could try them, though - maybe more complex
<electronics would help..
You need something you can saturate hard. Tape wound materials were
used a lot early on. It's not too hard to test an assortment of things
as you only need one.
Allison
>> Can you translate that to a size? I can imagine the size of a #4 nut
>> (I have several). I can't clearly picture how big the O.D. of a #2 would be.
>>
> Roughly .1375 across the hex faces.
>
>> > ...A good material for this is hypersil commonly used for transformers.
>>
>> Used for the windings or the core laminations?
>
> Hypersil is a silicon steel alloy and is used for laminations. Copper, is
> the wire.
I seem to have lost the attributions of much of the above, but...
I would have thought that transformer steel is _not_ a good material for cores.
Transformer steel is designed for making the hysteresis as small as possible, so
as to minimise core losses, etc. Whereas for core memory, you need a good sized
hysteresis because this corresponds to stored energy, which will drive the pulse
on the sense line.
(As I understand it, when you _don't_ flip a bit, the pulse on the sense line is
roughly that from the transformer effect in the core. If you _do_ flip a bit,
you get the transformer effect, plus a pulse of stored energy from the core.)
Rather than using steel nuts - which may be very inconsistent in their magnetic
properties - would ferrite beads, as used for interference suppression, work?
Or to they have too small a hysteresis like transformer steel?
> That is only part of the picture. Core size affects switching speed and
> current needed to switch. Compounding this is more wire means
> resistance, heat and inductance all influencing how fast you can switch.
> Core is where magnetics, analog and digital intersect.
Nice Description, Allison. I like it.
Philip.
<>that were clearly under 1.4kw. The codes are aimed at providing reasonabl
<>power. Here a 15A/115v is the nominal and 115V/20A is a max
<
<No, it isn't. I have several 115V 30A circuits in my computer room -
<this being an extremely common rating on the power controllers used
<in smaller DEC systems - and looking at the codes and the Hubbell catalog
<it would seem that 60A circuits are standard things as well.
Tim,
I should have qualified that as common residential and business circuits.
Sure it's possible to go to 60A, how many houses nomially have that?
(don't include mine).
Allison
--- Tony Duell <ard(a)p850ug1.demon.co.uk> wrote:
> > > The wire used should present little trouble as fine wire can still be
> had.
> >
> > Any idea how to estimate the gauge? I know I'd need red and green
> enameled,
>
> Do you have/can you borrow a micrometer?
As a matter of fact I do. I should have thought of that before.
> There is a prototyping system, made by a company called 'road runner'
> that uses fine enammeled wire. I think it's 30swg or something like that.
Is this like Augat Unilayer?
> > How much oomph would it take to induce a stable magnetic pattern in a
> > steel nut?!?
> >
> > Anyone with a EE degree and a copy of Spice care to take a stab at it?
>
> Or alternatively do it properly and _build_ the darn thing :-).
I do not believe my engineering and math skills are adequate to design it,
but given the specs, I sure could _build_ it. If anyone is considering
this, please bore out the threads of the nut (if you use nuts) before
determining the saturation current. It will minimize mechanical wear on
the insulation. I may just go to the local fastener house and buy a box
of #2 nuts and build a mat of this just to hang on the wall. ;-)
-ethan
-ethan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--- allisonp(a)world.std.com wrote:
> Correct, but the pulse that indicates the core switched is delayed in
> time Hence the critical slice time.
Ah! The light goes on!
> Core size affects this as does the select current.
That makes perfect sense.
> Actually the nuts have an adaquate hysteresis to make a demo core but it
> would not work useably well.
Funny you should mention demo core. I have had in the back of my mind for
several years now a project: demonstrate memory storage by building a mini-
core mat on top of an FPGA socket and drive it via some kind of parallel-
port A-D/D-A interface. The purpose of the demo would be to stick the
core mat into a ZIF socket, program it, display the bits on the screen,
remove the mat from the socket, turn it around and show how the bits have
moved... not particularly practical, but a good visual demonstration of
the technology. A special bonus is that the demonstrator can prove that
core is non-volatile by letting the audience see the plane out of the socket
between phases of the demonstration.
I'm thinking of a 4x4 or a 5x5 mat; nothing larger than 8x8. The test jig
could be even 2x2 inside a larger FPGA socket. The external circuit would
have to be able to select the half-currents on the X and Y planes, then
send a pulse and then time the return, yes? I have a general knowledge
of the sense amps and inhibit drivers for several PDP-8 models. Is it
possible to simplify that circuit if you knew that you had read cycle time
of several or tens of milliseconds? Perhaps by having one circuit to control
all the X lines, one circuit to control all the Y lines and some sort of
analog multiplexer?
> Ferrites used for beads have low permability. But since they are available
> I'd try one and see.
How do the different dimensions affect this all? (Most ferrite beads I've
seen are taller than their diameter (HoHo's, not KingDons, if you will).
In other words, the ferrite beads have a different aspect ratio compared
to the #2 nuts (or a standard ferrite core). How does this affect usability
as a memory device?
-ethan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Well, I recall that someone said, a while back, that the devil's in the
details. What I'm trying to do is place boundaries around this problem for
purposes of understanding its limits. Others who attempt to replicate your
work on other processors will want to know these things. From your
statement that the process produces a result of '*' for an invalid input,
which, apparently would include negative values, non-integers, and integers
of value 4000 or greater. If the input is presumed to be unsigned integer,
that solves much of the problem. Now, you want to store the output in
memory, presumably as ascii characters, presumably as a null-terminated
string, and perhaps (optionally) echo it to the screen in the aftermath of
your run. Does that sound like a reasonable thing to do?
How do we tell this program what string of numbers to convert? Is this
someting you want to put into memory as a null-terminated string of binary
values, or would you prefer a single word for each value, with a null
terminating the input array or a fixed string length?
It's still simple enough. I can even understand it myself, I think.
Dick
-----Original Message-----
From: Sean 'Captain Napalm' Conner <spc(a)armigeron.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, April 18, 1999 12:23 PM
Subject: Re: Program Challenge (was Re: z80 timing... 6502 timing)
>It was thus said that the Great Richard Erlacher once stated:
>>
>> There are a few details which have been left out of the specification for
>> this task.
>>
>> Does it require input validation?
>
> I think I specified that. The valid range of Roman numerals is 1 through
>3,999 inclusive. The routine does have to check that and construct a
>special string ( "*" ) if the input is not in that range.
>
>> Is the binary input pure binary, or is it BCD?
>
> Okay, that might be a valid point, but it's pure binary, not BCD.
>
>> Shouldn't it go both ways, i.e. shouldn't we also have to convert ROMAN
to
>> BINARY as well as BINARY to ROMAN?
>
> One thing at a time, please 8-)
>
>> What about the console I/O routine? Shouldn't there be some definition
of
>> how it's to be used? Should it be a call with the I/O character simply
held
>> in a register before/after the call?
>
> I liked Sam's suggestion of ``printing to memory'' as a way to avoid the
>complications of I/O in this, and if I didn't make this clear that the
>conversion was to be stored in memory, I'm sorry.
That should work. In fact, input could be done that was as well, placing
the input in memory and then executing the program from a debugger or with a
call from a HLL.
>> How much memory is used can be defined in two ways. (a) the number of
>> bytes, and (b) how much contiguous memory must be present in order to
allow
>> the code to be implemented. It requires 200 bytes of RAM is not a valid
>> statement if that RAM has to be scattered over a 32-KByte range.
>
> Uh ... okay ... gee ... I thought common sense would be enough here.
>
> The problem here is that I could say: Code segment size, data segment
>size, bss (dynamic) segment size and stack segment size, but that tends to
>lead to certain assumptions about how to code (at least to me). In modern
>systems, code and data are kept separate, but there's nothing really
>requiring that, and as you can see from my solution, I mix both code and
>data together, which was a common trick in the 8-bit era (and maybe used
>earlier as well).
This is an issue only because these systems have both ROM and RAM, and using
parts of each can bias the resource tally without really having any meaning.
>> If your
>> claim is that your code runs in 200 bytes of memory, it must be runnable
on
>> a computer having only 200 bytes of memory. If you can't figure out how
to
>> build a 200-byte RAM, then perhaps it might be more appropriate to
suggest
>> it requires only 256 bytes of RAM, which you can buy.
>
> I'm a software guy---building computers isn't exactly my forte. Besides,
>if I say my code only requires 200 bytes of memory, and I can't figure out
>how to build a computer with 200 bytes of memory (pretty easy for me 8-)
>then that means I have 56 additional bytes to play with, maybe by adding
>code to run blinkenlights or something.
>
> Besides, who wants to build a computer for this? Okay, except for Tony?
That's the ultimate test, though, isn't it?
>> Was the processor in question available in 1983? As I recall, the 6809
was,
>> but there are some which weren't.
>>
>> Now, for the more subjective aspects of the comparison, how was the code
>> initially generated? How long did it take to code the problem? How
long
>> to debug it?
>
> This I'd rather not include as this is very subjective. It only took me
>about an hour or so to code and debug the program, but I'm a software guy
>that's been programming for 15 years or so, and the 6809 was my first CPU I
>learned assembly language on. It might take Tony four hours to get a
>similar program running. By the same token, he could probably get a simple
>computer system running in an hour that would take me four hours.
>
> It really depends upon how much experience you have both in programming
>and the CPU in question. I know that it would take me longer to write this
>program for the 6502 or the Z80, both of which I've never written code for
>(but I can read code for each CPU).
>
>> How is the 6809E relevant to the timing of the Z-80 and 6502?
>
> Nothing at all, except as an outside reference. That, and I don't really
>know Z80 or 6502 code (nor do I have development systems for these chips).
>
Its certainly an outside reference. It may be a challenge for everyone to
improve on it. . . We'll see, I guess
> -spc (Gee, I thought it was pretty simple problem myself ... )
>
>
As many of you all know, I'm trying to get an HP2000 TSB system up and
running. Purist that I am, I am using only original HP gear for it. However,
I'm also thinking ahead to the power consumption (ie the Amps) that the
system draws. I might not be able to afford to keep it online all the time.
So I have been starting the mental exercise of laying out how to best design
an emulator. The overal design layout is complete, but there is a low-level
issue I can't get my brain around and thought someone here might have some
input on the following:
The 2100A/S or 21MX/E systems were microcoded. Matter of fact, the control
processor on those systems is 24 bit, while the appearance at the
non-microcode level is a 16 bit machine. Should I write my emulator to
process the microcode instructions or the 2100A/S or 21MX/E instruction set
that the microcode implements? I was planning on the latter, however one
argument for the former is that HP did release special ROMS to extend the
instruction set for special applications (DMS for one, SIS, FFP, 2000Access
IOP for others). I would like users to be able to set the emulator to a
given hardware configuration (ie. command line options to turn on the DMS,
SIS instruction sets) rather than assuming a machine configured with all
available options. Each I/O interface card would have it's own loadable
module, so they can select what cards are installed in what slots, etc. I
just have the gut feeling that there's some obvious reason to do one or the
other that I'm missing...
Yes, I am aware of Jeff Moffat's 2100 emulator; nothing at all against his
code, but I'd just prefer to start from scratch (this means I'm idiotic or
masochistic or more than likely both) <Grin>. I'll write it in C on Unix
(FreeBSD) but make sure the makefiles are setup so DOS porting is just a
configure argument. Heck, the whole project is worth it just to see TSB
running on a Pentium II 400!
Any input appreciated!
Jay West
Hi!
I was just given some *.cam files. They're supposed to be image files of a
computer to put on my webpage (classic computer section). They were taken
with a digital camera, and downloaded to a PC. My question is: how in the
heck do I view them?? Anyone have any idea?
--
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
>Please ? Equipment that assumes Neutral (protective ground) = Ground ?
>At least over here this kind of device is _strictly_ forbiddeen since
>>30 years, and I assume it's the same all over Europe. Only machinery
>with distinctive Ground and Neutral or with isolated interior is allowed
>(the wide variety of outlet/plug systems within Europe did support the
>later one a lot, since most are at least compatible for 'hot' and Ground
>pins :).
In all of the UK equipment that I service from one particular manufacturer
they only switch and fuse the one hot lead. The Neutral is "assumed to be
at / near ground so it need no protection. If this is wired to a standard
US residential then you will have no fuse protection on one lead. It will
also be floating when switched off waiting to bite you.
See the following attempt at ASCII art wiring which looks wrong if not
viewed fixed width.
US residendial 240 /120 mains power
_______240V_________
| |
Hot____ Neutral_____Hot
| | |
|__120V___|__120V___|
|
|
|
Ground
This is tied to Neutral
at service entrance ONLY.
>standard voltage (with an upper limit of 120) which comes to 200V (208V),
>and not 220 - and 200 is definitive to low to drive 230V (240V) equippment.
>Not even the old standard 220V Eq will run properly in all cases.
This is where the US confuses people. In commercial 3 phase it is 120 phase
to neutral. 208 phase to phase.
Again with neutral tied to ground at the service entrance ONLY.
Looks like it takes 240v. Can it be changes to 120v I wonder? I'm not really
into micro's, but I do remember the Ohio Scientific stuff vaguely....
Jay
-----Original Message-----
From: Andrew Davie <adavie(a)mad.scientist.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, April 19, 1999 10:19 AM
Subject: FA: heads up; OSI Challenger 1P
>This is sort of a heads-up. Even though I am the actual "seller", I'm
>really putting this item up for a close friend. I'd buy it myself if I
>could, but I'm in an anti-aquisition mode myself. It's an OSI Challenger
1P
>computer + documentation
>http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=93182204
>There are some nice piccies even if you're not interested in bidding.
>HI to all :)
>A
>
>
>
In-Reply-To: <m10YZmF-000IyOC@p850ug1> from "Tony Duell"
You are right, not only _could_ I argue that the FPGA version is
not microcoded; I strongly assert that it is not. (Unless you
meant to have the FPGA be functionally equivalent to the ROM. But
I *think* you meant it to subsume other parts of the processor to
try to muddy the water. Because if the FPGA is just a ROM substitute,
then it is an obvious control store for the microcode.)
No microcode --> not microcoded.
It's just a question of implementation really, not a fundamental
design characteristic. Now, if you make writable microcode, you've
exposed the innards to the programmer, and it becomes a part of
the functional description of the thing. But if you don't do
that, the programmer can't tell the difference; a microcoded and
non-microcoded machine could behave identically.
I'm sure we could carry this to the point that there is a grey area,
but I don't think we're there yet. It's the philosophical problem
of the beard, right? You trim a little off, and it is still a beard.
But if you keep doing that, eventually you get to a point where you
are quite sure there is no beard. Somewhere in between, was there
one atom that you cut off that made it from a beard into a non-beard?
What if you didn't really cut that atom off, but just stretched its
molecular bonds to the limit...?
Of course, it seems to me that so far you've been considering a case
of five o'clock shadow, and wondering it if might be a beard. :-)
I guess, if it has some kind of counter selecting bit-patterns that
control the flow of data in the CPU, I could call it microcoded.
If there is no cohesive place from which such bit patterns are
retrieved, then it is not. (Now, I'm sure you'll make me eat those
words. :-) )
It just struck me that the microcode in a CPU is very much like the
rules of an expert system. The whole point in an expert system is
to isolate the knowledge from the program, so you can tinker with
the former and not get involved in the later. Microcoding lets you
abstract away the complications of the control logic, reducing it
to "these bits at that time-step" thinking, without getting bogged
down in gate propagation delays or chip counts. Lets us programmers
get a little closer to the hardware, without the obvious dangers of
letting us too near the soldering irons. :-O
Ah. There's the grey area. Take all the logic around your state
FF's and registers. Call it a microcode ROM. Of course, the fact
that it is spattered all over your CPU board weakens the argument
that it is a unit in any way, but then maybe you could rearrange
the board to put all that gorp on the left side...
So now I have a fuzzy definition: a CPU is microcoded to the degree
to which the control logic is encapsulated in the form of a control
store. Most real world cases are probably close to 100% or 0%, but
I have no doubt we could construct any degree of set membership that
we like.
I might be willing to stop prattling on about this now. Maybe. :-)
Bill.
On 17 Apr 1999, the Insanely Great ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
] > Do you mean to say that _all_ computers are microcoded? After all,
] > the control logic can always be modelled by some number of state FFs
] > and a large-enough ROM, couldn't it? Or is your claim that there is
] > no such thing as microcoding? That strikes me as far-fetched as well.
]
] This is the problem. Obviously both of those statements are false based
] on our usual use of the term 'microcoding'. But it's hard to see just
] where to draw the dividing line.
]
] > The difference is that a ROM is easily replaceable; slap in another ROM
] > or EPROM with different microcode burned in, and you've got an entirely
]
] OK, here's a counterexample.
]
] Consider the PERQ. It's microcoded. It's obviously microcoded - there's a
] 16K*48bit _RAM_ that stores the microcode. And there are supplied tools
] to rewrite that microcode.
]
] Now suppose I get a large enough FPGA (I don't think any of the ones
] currently available are large enough, but). I stick it on a board. And I
] provide a tool that does the following :
]
] It takes PERQ microprogram, and combines it with a description of the
] rest of the CPU logic. It then optimises the result, and programs the
] FPGA accordingly.
]
] The result is a processor that runs exactly the same programs as a PERQ
] with that microcode. But you could reasonably argue that the FPGA version
] is not microcoded - you would look in vain for anything resembling a
] control store in the FPGA.
]
] Perhaps the term 'microcoded' should be applied to the original design
] philosophy - if the control logic was _designed_ as a program, then it's
] microcoded.
--- Allison J Parent <allisonp(a)world.std.com> wrote:
> <sort of a "one from column A, two from column B" approach.
>
> Not likely but ther eis anotehr totally different problem, asymetric noise
> pickup masking the cores switching.
I hadn't thought of that. Good point. Another problem is that "worst case"
diagnostics won't necessarily be worst case anymore.
> You're further ahead fixing the mat.
Sigh. It looks like *quite* the challenge.
> The wire used should present little trouble as fine wire can still be had.
Any idea how to estimate the gauge? I know I'd need red and green enameled,
perhaps another color like yellow? I also wonder what they used to insulate
the splices? It appears to be some kind of paint.
> As an aside to this with the lamers trophying the mats. Most often the
> mats are intact so someday they could again be spares.
True.
> The best one I've ever seen was not real but instead used small nuts and
> three colors of wire to make a real looking mat of some 64 or 128 bits.
What size nuts?
> I'd bet that with the right currents and timing you could even store data
> in it.
Oy! The core circuit that I copied for my 12th-grade drafting project used
7.5VDC as the half-voltage. How much oomph would it take to induce a stable
magnetic pattern in a steel nut?!? I would think that enameled insulation
would cook right off the wire.
Anyone with a EE degree and a copy of Spice care to take a stab at it?
-ethan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Okay, I have been able to test the routine, and in fact it did work
first time it executed... It didn't assemble first time because I
had left out a local symbol, but with that corrected it built on the
second try.
In designing the algorithm I used, I noted that converting to Roman
is the same as converting a binary value to decimal (finding the
digit 0-9 for a given power-of-ten) but with the added step of
converting that digit to the appropriate characters for the given
power-of-ten.
The routine has a table of values which are used for successively
subtracting a power of ten from the value until it has a digit 0-9 and a
remainder (which is handled by decreasing powers of ten on successive
passes through the loop). It also maintains a pointer to the current
roman numeral corresponding with the current power-of-ten.
The conversion for 0-3 is easy, it simply outputs the requisite number
of the current roman numeral. For 4, it outputs the current numeral
followed by the numeral one higher. For 5-8, it starts by printing
the numeral one higher followed by 0-3 of the current numeral. For
9, it outputs the current numeral followed by the numeral two higher.
At the end of each loop, the power-of-ten pointer is incremented to
the next entry, but the pointer to the roman numeral is also incremented
by two. This way, the 'current numeral' pointer is always pointing to
'M', 'C', 'X', or 'I'. Since no number in the range which can be
converted required numerals above 'M', I only have to worry about C,
X and I. The numeral one higher than each is, respectively, D, L and V.
The numeral two higher than each is, respectively, M, C and X.
That's it...
I didn't get info on cycles, but I did for number of instructions, which
I included in the comments for the routine.
One last thing - since there are quite a few members in the family
of pdp-11 CPUs, the code is written to run correctly on any one of
them. There are no restrictions, so using the T-11 (as I think
Allison mentioned) would be possible.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry(a)zk3.dec.com |
| Unix Support Engineering Group | (home): mbg(a)world.std.com |
| Compaq Computer Corporation | |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
- - - - -
.SBTTL CVBTAR - Convert Binary to Ascii Roman Numerals
;+
;
; Copyright (c) 1999 by Megan Gentry
;
; CVBTAR
; Converts a binary value to string of ascii characters which
; represent the value in Roman Numerals.
;
; Call:
; R0 = Binary value to convert
; R1 -> Storage space for resulting string (nul-terminated)
;
; Returns:
; R0 = zero
; R1 -> Byte beyond end of nul-terminated string
; other registers are unaffected as they are saved and restored
;
; Notes:
; o Valid range for input is 1 to 3999.
; o Roman numerals are:
; M 1000
; D 500
; C 100
; L 50
; X 10
; V 5
; I 1
;
; 60 words (120 bytes) of code
; 5 words (10 bytes) of data
; 7 bytes of text
; 3 words (6 bytes) of stack used
;
; Code ROMable: yes
; Data ROMable: yes
; Code Reentrant: yes
; Data Reentrant: yes
; Undefined opcodes: no
; Undefined behaviour: no
;
; Value Instructions executed
; 0 5
; 4000 7
; 1 78
; 3999 185
; 3888 220
;
;-
.PSECT .CODE.
.ENABL LSB
CVBTAR:
; Range check the input
TST R0 ;Is it valid?
BLE 100$ ;Nope...
CMP R0,#3999. ;Maybe, check upper limit...
BGT 100$ ;Nope...
; Save registers and do some setup
MOV R2,-(SP) ;Save R2
MOV R3,-(SP) ; and R3 while they are used
MOV #BTDTAB,R2 ;R2 -> Decimal conversion table
MOV #ROMCHR,R3 ;R3 -> Roman numeral character list
BR 20$ ;Just starting conversion...
; Head of the loop
10$: TST @R2 ;End of the conversion table?
BEQ 90$ ;Yep, conversion should be complete
20$: MOV R0,-(SP) ;Save current binary on stack
CLR R0 ;Reset R0 for conversion
30$: INC R0 ;Bump count for this digit
SUB @R2,@SP ;Reduce by current factor of 10
BHIS 30$ ;Continue if still positive...
ADD (R2)+,@SP ;We went too far, add it back
; (and bump conversion table pointer)
; remainder is still on stack
DEC R0 ;Reduce the count
BEQ 80$ ;If zero, no characters to output
; Here we convert the decimal digit to Roman Numerals
CMP R0,#9. ;Is it a nine?
BNE 40$ ;Nope...
MOVB @R3,(R1)+ ;Yes, it converts to current numeral
MOVB -2(R3),(R1)+ ; followed by the numeral two higher
BR 80$
40$: CMP R0,#4. ;Is it a four?
BNE 50$ ;Nope...
MOVB @R3,(R1)+ ;Yes, it converts to current numeral
MOVB -1(R3),(R1)+ ; followed by the numeral one higher
BR 80$
50$: SUB #5.,R0 ;Is value five or greater?
BLT 60$ ;Nope, in range zero to three
MOVB -1(R3),(R1)+ ;Yes, prefix with one higher numeral
SUB #5.,R0 ; followed by one to three current
60$: ADD #5.,R0 ;Return value to range zero to three
BEQ 80$ ;It was zero, nothing to do...
70$: MOVB @R3,(R1)+ ;Store a numeral
DEC R0 ;More to do?
BGT 70$ ;Yep...
; Tail of the loop
80$: ADD #2,R3 ;Bump the numeral pointer by *2*
MOV (SP)+,R0 ;Pop the remainder (already popped
; the power of ten pointer)
BNE 10$ ;More conversion to do if non-zero
; Clean-up
90$: MOV (SP)+,R3 ;Restore previously saved R3
MOV (SP)+,R2 ; and R2
BR 110$
; Out-of-range string
100$: MOVB #'*,(R1)+ ;Out-of-range conversion string
; String termination and return
110$: CLRB (R1)+ ;String is to be nul-terminated
RETURN
.DSABL LSB
; Conversion data
.PSECT .DATA.
; Binary to decimal conversion table
BTDTAB: .WORD 1000.
.WORD 100.
.WORD 10.
.WORD 1.
.WORD 0 ; ** Table Fence **
.PSECT .TEXT.
; Roman Numerals (1st, 3rd... entries match entries in BTDTAB)
ROMCHR: .ASCII /MDCLXVI/
.EVEN
.END
>> Well I was at an American run management course last year in Newcastle. One
>> of the (male) attendees made the comment that he was cold and that he was
>> going to get a jumper. This caused a hysterical reaction by one of the
>> female presenters - apparently from her part of the USA a jumper is a dress!
>
> Farzino, a "jumper" is a dress anywhere in the US, specifically a
> dress of a style rarely worn once puberty kicks in. Possibly the
> standardisation of that nomenclature resulted from the fact that
> that's what was used in the old Sears-Roebuck catalogs that were
> distributed nationwide.
That sounds like what I would call a "pinnafore dress". In the UK a Jumper is
usually a sweater. The only exception I have met was in the _Manual of
Seamanship_, published by the Admiralty in (I think) 1938, where it lists the
kit issued to sailors, with illustrations. There the sweater is called a
"Jersey", and "Jumper" refers to something resembling a football shirt. Well,
the top half of a sailor suit anyway :-)
Philip.
I was just wondering (mainly for refreshment purposes) if any
ListMembers in the Southern California area who might be thinking of
gathering at my place after TRW for a vintage computer crawl...
might drop me a line or mention you are interested... I have
somewhat limited parking as well, and I was just trying to get an idea.
If any SoCal Classiccmp List Members are reading this and haven't
yet read the previous invitations, I am sponsoring a Vintage
Computer Collection open house this saturday... e-mail me for
details or see previous messages.
Cheers and Thanks!
John
-----Original Message-----
From: Hans Franke <Hans.Franke(a)mch20.sbs.de>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, April 20, 1999 4:49 AM
Subject: Re: z80 timing... 6502 timing
>> Some things in this contest that sound reasonable to me;
>
>> Input and output are to memory resident buffers.
>
>> Inline code is too boring, and subrountine calling too important, so the
>> "task" should require perhaps modules; maybe make the contest half a
dozen
>> subroutines which get called from a contest defined main program (using
>> some typical non asm language like C or pascal).
>
>> Contest submissions could be a simple binary file, file length,
predefined
>> jump table for subroutines, the actual code. Some third party, can run
the
>> code and time it on the hardware of their choice.
>
>Nice, but with these things, like internals of the system for input/output,
>binary and similarities, you tie again all down to a single system to
>use - we loose the idea of a cross platform competition where only basic
>processor features are measured (see also the subject).
>
>Gruss
>H.
>
>--
>Stimm gegen SPAM: http://www.politik-digital.de/spam/de/
>Vote against SPAM: http://www.politik-digital.de/spam/en/
>Votez contre le SPAM: http://www.politik-digital.de/spam/fr/
>Ich denke, also bin ich, also gut
>HRK
In a message dated 20/04/99 10:35:53 Eastern Daylight Time,
george(a)racsys.rt.rain.com writes:
<< In the mean time I notice the ebay bid is up to $180. I wonder what a
c4mf or a c8df would fetch?
George >>
harrumph, even an IBM pc convertable (5140) was up to ~$120 yesterday! i knew
i shoulda bought that one i saw last week for cheap...
>that were clearly under 1.4kw. The codes are aimed at providing reasonable
>power. Here a 15A/115v is the nominal and 115V/20A is a max
No, it isn't. I have several 115V 30A circuits in my computer room -
this being an extremely common rating on the power controllers used
in smaller DEC systems - and looking at the codes and the Hubbell catalog
it would seem that 60A circuits are standard things as well.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927