David Griffith <dgriffi at cs.csubak.edu> skrev:
> On Sun, 3 Sep 2006, Johnny Billquist wrote:
>
> > > David Griffith <dgriffi at cs.csubak.edu> wrote:
> > >
> > > Frotz???
> > > Why on earth base it on Frotz? Frotz is written in C. You'll
never get
> > > anything meaningful written in C to run on a PDP-8.
> > > Something written in Z80 assembly is just about equally meaningless.
>
> I mentioned Frotz because it seems to be used as a base for all sorts of
> strange ports. The Z80 reference was part generalization and part
wishful
> thinking.
You might be right there. :-)
> > > No, you'd just have to write it from scratch. Nothing strange about
> > > that, and doing something about V4 and V5 games isn't that difficult
> > > either. Given a little time I sure could whip one together, but
for now
> > > I'll leave the exercise to someone else.
> > > I've already written one Z-machine interpreter in MACRO-11. It deals
> > > with anything V1 to V8, except for obvious limitations (no sounds, no
> > > graphics, no mouse...)
>
> Where can I find this MACRO-11 interpreter?
ftp://ftp.update.uu.se/pub/pdp11/zemu.tar
Johnny
Jay,
I don't see any record of your original post of this question in the
cctalk digest, so I'm switching over to the cctech list. The only post on
this subject is Ray's reply today.
In reply to your question, I worked on the software for the Quantum Link
online service including fast loader disk routines. We gave the C64 a pretty
good work out, and the software ran just fine on the C128/1571. The only
machine we had problems with was the SX64 where the fast loader would hang
shortly after starting a disk load. They hadn't terminated the serial bus
correctly which caused some ringing in the lines. But by pressing your
finger against the serial bus port connector or by connecting a serial bus
cable to the serial port the load would continue and finish.
Remember that many pieces of C64 software back then used unimplemented
opcodes in their protection schemes. I don't believe that the C128 had any
problem with this software.
--Doug
>Message: 1
>Date: Sat, 02 Sep 2006 12:29:13 -0400
>From: Ray Arachelian <ray at arachelian.com>
>Subject: Re: commodore 64/128 question
>To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
>Message-ID: <44F9B159.3030204 at arachelian.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>By all means, go for the C128. They're a lot better.
>.......................
>
David Griffith <dgriffi at cs.csubak.edu> wrote:
> On Sat, 2 Sep 2006, Gordon JC Pearce wrote:
>
>
>>Interesting. Looking (very quickly) at the Z-machine spec, it seems
>>fairly simple. This gives me a good excuse to start on my PDP-8
>>emulator again - at least that way if I need more core, I just need to
>>change a #define instead of starting a big long thread about
>>semiconductor memory ;-)
>
> I don't mean to discourage you, but you might be in for more challenge
> than you bargained for. I asked Brian Moriarty about the feasability of
> porting a modern Z-machine emulator to 6502 machines such as the Commodore
> 64 and Apple IIe. He replied that past V3, the abilities of these
> machines were seriously taxed and that's why Infocom abandoned that class
> of machines for their later work. The full discussion can be found in the
> Frotz documentation. Based on this, I don't recommend using Frotz as a
> starting point.
>
> Look instead at ZXZVM, a Z-machine emulator written in Z80 assembly for
> PCW machines. It should be reasonably easy to port to CP/M and/or ZSDOS.
> I'd love to see that one for my P112. Doing that may provide enough
> insight to port it to the PDP8.
Frotz???
Why on earth base it on Frotz? Frotz is written in C. You'll never get
anything meaningful written in C to run on a PDP-8.
Something written in Z80 assembly is just about equally meaningless.
No, you'd just have to write it from scratch. Nothing strange about
that, and doing something about V4 and V5 games isn't that difficult
either. Given a little time I sure could whip one together, but for now
I'll leave the exercise to someone else.
I've already written one Z-machine interpreter in MACRO-11. It deals
with anything V1 to V8, except for obvious limitations (no sounds, no
graphics, no mouse...)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
>From out in left field.. Questions and opinions solicited on
Commodore C128/1571.
In my ecelectic collection of machines I generally have either DEC hardware,
single board computers (IMSAI IMP48, KIM-1, SC/MP, Moto6800d1, NEC TK80 and
others) and CP/M machines (S100, Ampro, SB180, Kaypro, Epson, Osborne). Also
the occasional oddball like the TI99/4, TRS80 and a C128.
What I'm up to is why have a C128 amoung all that? It's not a great CP/M
machine. It's not very representitive of most CP/M machines and from
using it it's an afterthought that primary to design. So I'm considering
why I should keep it or unload it. I have no real exposure to the 6502
side of the system and the Commodore side of the world so there are gaps
there. So I'm trying to figure out if there is something to explore and use
or it's a "collection" item. The latter being something I have, keep
operational but rarely if ever use for much.
Flames not desired but opinions are.
Allison
I had heard that Apple did the DB-25 thing because the HD-50 hadn't been standardized yet and
they didn't have enough back-panel real estate on the Plus for a 50-pin ribbon/Centronics type.
Better Apple SCSI cables have enough girth to where I think they have the grounds internally,
but they are wired in the connectors up to fewer pins, or the shield, or somesuch hack.
For simple scanner use, a well-shielded (thick-girth) everyhing-connected DB-25 to DB-25 is
something that I've used in the past. The Apple SCSI implementation is not pushing the performance
boundary at all on the external port, I think it's asynchronous SCSI-1. Q950s and many PowerMacs have
dual-SCSI, so your scanner can be on "substandard" wiring without messing up your drive chain, not sure about
the 800 or 840.
I have an interesting SCSI cable - its a ribbon/pin-header but has shields for "external" use. I think it
might have gone with the ComputerVision CADDstation that I gave away (that had all pin-header connections
with some sort of funky ground wipe that would connect the shield on this cable.) Was this ever something
approaching standard, or was this CV proprietary (or was it not CV SCSI and just looks like it)?
--- Fred Cisin <cisin at xenosoft.com> wrote:
> On Thu, 31 Aug 2006 aliensrcooluk at yahoo.co.uk wrot
e:
> > Yeah, but it's often hidden.
>
> Not by default.
> If it has been hidden, it is because somebody
> explicitly and deliberately
> was trying to keep you away from it.
> Without user intervention Win2K installations will
> have it in accessories.
>
I had another search for "calculator" today
to find out what directory it was stored
in.
In the same directory I also found a Paint
program and one other program, which I
can understand why they would hide them
>from us.
But we work in a lab and do calculations on
a *daily* basis. Most of them are done by
the computers (special program made by
Scibertec), but some calc's we do manually.
>> snip <<
>
> > Now whenever I need it and it's not listed
> > under applications (we move about alot in the
> > lab and use diff computers each week), I just
> > do a quick filesearch, dump it on the desktop
> > and on the main drop-up (?) menu that appears
> > when you click on the Start button, incase
> > I have a screen full of windows.
> > Now almost everyone uses it (largely because
> > calc's are so hard to find in the lab).
> WHY BOTHER??
> Go to Start/Run and type Calc.
Didn't know you could do that.
> or
> Go to the command line, and type Calc.
>
Not sure we have permission [1] to go into the
CLI mode, and perhaps we might get suspicious
looks if we did.
> > The "scientific" mode includes binary, octal,
> > hex and decimal, aswell as proper maths
> > functions.
>
> Yes, but it refuses to do anything but integers in
> anything other than
> decimal!
>
> 3.0h/2.0h gives 1.8h, NOT 1.0
> 11 binary/10 binary is 1.1 binary, NOT 1
> 3.14159decimal is NOT 3h.
>
No offense intended, but are you sure it's not
set up for no decimal places, or perhaps
it's just MS's programmers being lazy? :)
I have never seen a hex number with a
decimal point anyway... do they exist and/or
serve a purpose, or was it just a demonstrate
your point?
[1] We don't have permission to alter the
computers time, as it's part of a very large
network.
Certain drives (eg. drive M: ) are also locked
away (not even displayed on "My Computer").
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
--- Chuck Guzis <cclist at sydex.com> wrote:
> Hey, I've got an old T-shirt that doesn't fit me a
nd
> is destined to hit the
> rag pile. It's a "Getting out the last bugs" shir
t
> with "SunStruck 4.1.89
> (Wanda)" on the back. Is this of any historical
> value or is it better used to wax the Volvo?
>
> Cheers,
> Chuck
>
Any chance of a pic?
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
>
>Subject: Re: Commodore hacking and hardware tricks (was Re: commodore 64/128question)
> From: "Zane H. Healy" <healyzh at aracnet.com>
> Date: Sun, 03 Sep 2006 13:32:51 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>At 12:55 PM -0700 9/3/06, Chuck Guzis wrote:
>>On 9/3/2006 at 8:42 PM Philip Pemberton wrote:
>>
>>>Chuck Guzis wrote:
>>>> What's a good substitute drive mechanism for the 1541/71? The drives
>>>that
>>>> come as factory original are pretty chintzy.
Funny, I was just looking at the 1571 and it's a Newtronics/Mitsumi 48TPI
two sided unit. The 1541 is from what I read a different beast.
>>>I'm not sure you'd be able to swap it out - isn't the head preamp on the
>>>1541
>>>motherboard, not a separate drive interface board?
>>>
>>Indeed it is. I hoped that perhaps generations of C128 hackers had found a
>>way around this by now. Silly me.
>
>I think it's called hooking your C64/128 up to a PC via a X1541 (or
>newer) cable, and using the PC as a drive via the appropriate
>software. This is one of the solutions I'm thinking of trying.
>Apparently it allows you to use the PC as a 1541, and to use emulator
>images.
Must be images as the '41 is GCR, the 1571 does do GCR and regualar
soft sector.
Allison
--- Fred Cisin <cisin at xenosoft.com> wrote:
> We have a winner! (very nicely done!)
> It shall be your responsibility to answer for
> Andrew B <aliensrcooluk at yahoo.co.uk> 's
> next query topic, and seeing to it that he follows
> this.
Hehe, I was gonna try and answer the first
question, but I admit I had no clue about q's
2 or 3. I don't no what the IEEE format is,
but I'd guess it would be Integer, Exponent,
Exponent, Exponent?
Besides, without a computer (or appropriate
calculator) it would have taken ages to
work out the binary for question 1 (the initial
few bits would have been easy but the rest...
urgh!).
Also.... in binary with binary points what would
the bits be known as that were below the
binary point?
If we have a value of say 11.111 which would
be the first bit (bit 0)? The 2nd one (reading
left to right) or the 5th one (far right)?
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
Hi,
I spent a few hours last night playing with different
scanning options and figured I would share my observations.
Definitely not a "scientific experiment" but, rather, "just
tinkering".
Image in question was just a page of text -- probably 8-10pt.
Laid out in two columns, quite a bit of whitespace. The
original image dimensions are about 8.5x12" (yes, 12, not 11).
[Sorry, in retrospect I should have used an 8.5x11 image as
this would be easier for most folks to relate to :< Instead,
I just set the scanner to scan half the available area (it's
a B-size scanner)]
First, I did a monochrome scan at 400dpi (which is where I
tend to do most of my scans). The resulting TIFF file was 2MB.
When viewed "on screen", the TIFF file (i.e., eliminating any
effects of the scanner software) was quite readable. No signs
of jaggies, etc.
I ran that image through various compressors (still sticking with
TIFF). "Packed bits" yielded a file size of 360K -- as did
Huffman encoding. LZW dropped this to 220K. CCITT3-1D encoding
dropped it to 217K while CCITT3-2D brought it down to 131K.
And, CCITT4 brought it down to 100K.
I then ran the same image at 800dpi (what the heck, let's live
dangerously!!). As expected, the original TIFF grew to 8M.
The CCITT4 variant grew to 250K. (I didn't bother with all
the other encodings as these two represent the aparent
extremes of monochrome representations *EASILY* AVAILABLE TO ME).
Next, I scanned the same image at 400dpi in *color*.
A 24 bit TIFF took a whopping 55MB. (can you say, "Sorry,
but we don't got no bananas...").
I then tried to save the image as a JPEG -- *guessing* at
appropriate compression/smoothing factors to get the resulting
image size down to ~1MB. (for reference, ASSUMING THESE
"settings" ARE PORTABLE, 4:2:2, 77 compression, 10 smoothing,
optimized but NOT progressive). I got lucky (?) and this
first pass gave me a 530K image.
With the 250KB *800*dpi B&W C4 TIFF in mind, I decided to
push the file size even smaller. (compression increased to 90)
This resulted in a 360K image. Even more squeezing (compr = 95)
got this down to 250K.
However, the *quality* of the image was very disappointing!
The 530KB version was quite "fuzzy" (not "jaggies", since JPEGs
are more continuous tone than a B&W TIFF, but, rather, "blurry").
The 360KB version began introducing noticeable artifacts that
were clearly not present in the original image. This got
worse in the 250K version.
Bottom line: the 100KB B&W TIFF was much better looking
than even the 530KB JPEG. And the 250KB B&W TIFF was so
"fine" that I suspect it is overkill (I doubt anyone or
anyTHING -- i.e. software -- could discriminate between
that at 800dpi and the 400dpi version).
I had earlier tried some gr[ea]y scale scans and convinced
myself I must be doing something wrong (as the sizes were
just so much larger) so I didn't pursue them. In hindsight,
a more scientific approach would try to JPEG encode those
monochrome representations as well. (I'm through experimenting
as I have the answer *I* want/need) Somehow, I doubt they
will prove to be more economical than the C4 TIFFs.
[N.B. the gr[ea]yscale scans are much "softer" on the eyes
(no doubt due to the continuum of "value")]
So, to answer *my* initial question (ages ago), 400dpi C4 TIFFs
are definitely "adequate". 800dpi are overkill. And, at
~100KB per page, they are quite "affordable".
We now return you to your regularly scheduled program...