test-drb April 1999

test-drb@ccmp.vtda.org

170 participants
1190 discussions

by steverob＠hotoffice.com

> > 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>

25 years, 8 months

Program Challenge (was Re: z80 timing... 6502 timing)

by edick＠idcomm.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 ... ) >

25 years, 8 months

How scarce (valuable) is core for the PDP-8?

by allisonp＠world.std.com

<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

25 years, 8 months

How scarce (valuable) is core for the PDP-8?

by Philip.Belben＠pgen.com

>> 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.

25 years, 8 months

heads up; OSI Challenger 1P

by allisonp＠world.std.com

<>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

25 years, 8 months

How scarce (valuable) is core for the PDP-8?

by ethan_dicks＠yahoo.com

--- 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

25 years, 8 months

Ongoing core memory discussion (was Re: How scarce (valuable) is core for the PDP-8?)

by ethan_dicks＠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

25 years, 8 months

Program Challenge (was Re: z80 timing... 6502 timing)

by edick＠idcomm.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 ... ) > >

25 years, 8 months

Is this a silly question - re: microcode

by jlwest＠tseinc.com

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

25 years, 8 months

*.cam files

by roblwill＠usaor.net

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>

25 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb April 1999