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

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon Apr 19 18:29:12 1999

Your points are valid. I didn't intend building a new computer to be seen
as a major construction project. It can be done with a processor, an
oscillator can, a PAL, two memory IC's, and a UART, e.g. 16C450. As I said,
it should take very little time, and the circuit could be built with both
processors in the same circuit, perhaps with only one inserted at a time.
It's not necessary, but it's the cleanest way to do the job if you want to
participate yet haven't got a running system with one or both of these
processors.

By the way, if I were picking a processor for almost any job, these would be
pretty far down the list, not because they're bad, but because others are so
much more convenient.

One other thing I'd say, though, is that it's perhaps a bit questionable
publishing code as yet because it will pollute the idea pool (no reflection
on the quality of the submitted code) in that those who read it over (which
I haven't for that reason) will potentially have their own approach
influenced by seeing someone else's.

There ought to be a bit of time allowed to pass while folks contemplate the
cosmic oneness and decide what they'll do.

Dick
-----Original Message-----
From: Sean 'Captain Napalm' Conner <spc_at_armigeron.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Monday, April 19, 1999 1:58 PM
Subject: Re: Program Challenge (was Re: z80 timing... 6502 timing)


>It was thus said that the Great Richard Erlacher once stated:
>>
>> Well, I recall that someone said, a while back, that the devil's in the
>> details.
>
> I'll say 8-)
>
>> 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?
>
> Yes. The actual code being timed is the conversion only, not the output
>part, which is why the conversion is being stored in memory.
>
>> 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?
>
> Well, if it's extended to read in a Roman number and covert it to binary,
>then yes, you read from a NUL terminated string. That way, you can test
>both sides of the program. But that's IF it's extended. I've yet to see
>anyone else offer any code for the presented problem.
>
>> > 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.
>
> Which is why I specified that the conversion program be callable as a
>subroutine---to isolate the program from the specifics of the operating
>system/monitor used to test it.
>
>> > 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?
>
> If (and it's a big if) I build a computer, it's going to be based on a 32
>bit chip minimum (like the 68k or ARM). And it's not going to be for this
>contest either 8-)
>
>> >> 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
>
> I'm sure a cycle or two can be shaved off here and there, but I haven't
>gone back over it myself. Heck, I've yet to see anyone comment on the code
>itself.
>
> -spc (Or are we having more fun discussing the problem than working on
> it?)
>
Received on Mon Apr 19 1999 - 18:29:12 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:31:44 BST