On 2012-02-08 01.37, Ethan Dicks<ethan.dicks at gmail.com> wrote:
>
> On Tue, Feb 7, 2012 at 12:51 AM, Cameron Kaiser<spectre at floodgap.com> wrote:
>>> >> ?I've been trying to figure out if the PDP-8 could handle C, and
>>> >> the answers I get range from "I don't know" to "Definitely not".
> I am not aware of a C compiler for the PDP-8, but I think it would be
> exceedingly difficult to write one if were possible at all (I've done
> a lot of system and embedded code in C and debugged it in assembler,
> so I know a bit about the syntactical mapping that goes on with C
> abstractions to the instruction sets of MC68000s, VAXen, PDP-11s,
> etc).
Everything is possible. The main question is how slow it would be.
>>> >> Something I'd really like to see is a Z-machine running on the PDP-8.
> I would like that too. I've even thought a lot about it. IMHO,
> anyone who does it will be writing the Z-machine in PDP-8 assembler,
> just like what was done for the Z-80 and the 6502 for 1970s and 1980s
> micros. I_think_ the Mac Z-machine was the first written in C, but I
> could easily be mistaken on that. I know there were official
> Z-machines written in C for the Mac and the Amiga, and probably the
> later ones on the PC (not sure about the early v3 interpreters for
> DOS).
>
> I like Frotz. Frotz is huge compared to the 6K-8K early 8-bit
> interpreters. It gets more dicey trying to ask a 12-bit machine with
> 4K pages to emulate a 16-bit virtual machine. I would consider it a
> win if one could fit the Z-machine code in 2 fields with enough space
> left over for a 2-page system handler and a 1-page line printer
> (SCRIPT) handler, using any memory above 8K for object data and game
> file buffers. Three fields seems plausible. A few years back, I
> assisted with a modern from-scratch Z-machine effort for ElfOS on the
> 1802 (that I was showing off at an early VCFmw). On a 32K Spare Time
> Gizmos Elf2000, once the interpreter was loaded and the object tables
> were loaded, there was very little room to buffer the game - I think
> it was on the order of 1-3 512 byte disk blocks. You can fit a v3
> game and interpreter in 32K, but to do it in less would probably
> require a read-write virtual memory scheme on the object data
> (fortunately, a full boat on a PDP-8 is 32K 12-bit words not 32K 8-bit
> bytes - that helps too).
Frotz is nice in its way, but totally unusable if you want to look at
doing something on a PDP-8.
I think two fields for all the code of the Z-machine itself is possible.
Including drivers, yes. Depending on the size of the game, you'll have
different amount of memory to play with after that.
I assume you by "object tables" mean the in-game read/write memory.
I can tell that ZEMU on the PDP-11 can handle any V1 to V8 games
dynamically, and takes about 32Kbyte of memory to do that. The rest is
used/usable by the game itself.
To write a V3-specific interpreter, as well as skipping some fancy
screen handling that ZEMU do, it should need way less.
> Strangely enough, I was just thinking about a 12-bit Z-machine this
> week. Anyone out there have 12-bit coding experience and have time to
> answer a few questions about OS/8 and file interchange from the 8-bit
> outer world?
Sure. Go ahead.
And then allison <ajp166 at verizon.net> wrote:
On 02/07/2012 05:39 PM, Ethan Dicks wrote:
>> On Tue, Feb 7, 2012 at 12:51 AM, Cameron Kaiser<spectre at floodgap.com> wrote:
>>>> I don't think the PDP-8 could.
>> I gotta say that I don't think so either.
>>
> It's not impossible though you might have a hardware abstraction to
> deal with recursion and addressing. But it will not be pretty.
Right. You need to make some design decisions on how to implement some
things in software that other machines do in hardware, but things like a
stack is not really that hard to write.
>>>> Something I'd really like to see is a Z-machine running on the PDP-8.
>> I would like that too. I've even thought a lot about it. IMHO,
>> anyone who does it will be writing the Z-machine in PDP-8 assembler,
>> just like what was done for the Z-80 and the 6502 for 1970s and 1980s
>> micros. I _think_ the Mac Z-machine was the first written in C, but I
>> could easily be mistaken on that. I know there were official
>> Z-machines written in C for the Mac and the Amiga, and probably the
>> later ones on the PC (not sure about the early v3 interpreters for
>> DOS).
>>
> Its likely doable but it would take work. Keep in mind that an -8 maxes
> memory at 32Kwords. that means bigger will have to have a mechanism
> for swapping to storage.
>
> Keep in mind the Z80 did not ahve many of the addressing modes of C.
Right. A Z-machine for the PDP-8 is definitely doable. It might not be
that fast, but it would work.
>> A few years back, I
>> assisted with a modern from-scratch Z-machine effort for ElfOS on the
>> 1802 (that I was showing off at an early VCFmw). On a 32K Spare Time
>> Gizmos Elf2000, once the interpreter was loaded and the object tables
>> were loaded, there was very little room to buffer the game - I think
>> it was on the order of 1-3 512 byte disk blocks. You can fit a v3
>> game and interpreter in 32K, but to do it in less would probably
>> require a read-write virtual memory scheme on the object data
>> (fortunately, a full boat on a PDP-8 is 32K 12-bit words not 32K 8-bit
>> bytes - that helps too).
> That and if you do text in six bit ascii you get two cars to a word.
Right. But that is not much help for the Z-machine, which packs text
inside the games in its own format anyway. There is very little text
required in the Z-machine itself.
>> Strangely enough, I was just thinking about a 12-bit Z-machine this
>> week. Anyone out there have 12-bit coding experience and have time to
>> answer a few questions about OS/8 and file interchange from the 8-bit
>> outer world?
>>
> Some here, not a lot as I've not run OS/8 in a long time. FYI
> a suitable dev system would be a DECmateII or III running OS278.
If you have questions about OS/8 or PDP-8 issues, feel free to ask. I
only read this list in digest mode, so please cc me directly as well.
> The biggest thing to watch for in PDP8 code is recursion as you
> need a software stack and handler to preserve data/addresses.
Not really needed. The Z-machine implementation itself is more or less
an abstract CPU, and does not really need to do any recursion. However,
the Z-machine games themself can do recursion. But as a stack for this
purpose is a part of the requirement of the Z-machine itself, it will
just work, if you implement the Z-machine.
> The DECmates had the 6120 and that implemented IOTs to create
> a address and data stack( hardware can be built to do that in
> any omnibus 8). The unique PDP-8 IO made doing things like that
> more common than would be guessed.
Right. But on an Omnibus machine, the easy way would be to instead have
a small subroutine that push/pop on the stack, instead of having to
built new hardware.
Johnny
On Feb 8, 2012, at 1:21 PM, David Riley wrote:
>
>On Feb 8, 2012, at 1:14 PM, Glen Slick wrote:
>
>> On Feb 8, 2012 8:49 AM, "Kevin Reynolds" <tpresence at hotmail.com> wrote:
>>>
>>> Can I put in a SCSI controller on the QBUS of a microvax II or III? I
>> really want to keep the QBUS as it is entirely different than everything
>> else I have. Do you know if there is SCSI support inVMS 5.2?
>>> Kevin
>>
>> You are not really concerned about native SCSI support but rather MSCP
>> (disk) and TMSCP (tape). If the OS supports an RQDX controller it should
>> support an MSCP SCSI controller such as the usual CMD CQD Q-bus SCSI
>> controllers.
>
>To my knowledge, VMS doesn't really even see past the MSCP at all; there's
>not much way it could distinguish between a SCSI disk on a CQD-220 and an
>MFM disk on an RDQX3.
>
>
Perhaps some confusion arises due to VMS having native support for SCSI
controllers in later machines such as the Microvax 3100?
Lack of this native support in early versions of VMS would cause difficulties
using the SCSI controllers in a 3100 but would not be an issue for a QBUS SCSI
controller which emulates an MSCP controller.
Regards,
Peter Coghlan.
Hi all,
Does anyone have a spare Acorn mouse, either RISC PC/A5000 (rounded
profile) or Archimedes (angular brick) style?
I can live with broken switches (got a bag of those!) and "it needs a
good clean", but the motion sensors need to work, and it must have a
mouse ball and the cover for the "ball pit".
For anyone who doesn't know what these look like -- they're usually
branded either Logitech or CPC, and have a nine-pin Mini-DIN plug on the
end of the wire. Colour is almost always cream (or murky yellow if
they've been in the sun) or white for the CPC ones.
Basically I need one for my A3000... the blasted PS2Mouse adapter
doesn't fit!
Alternatively if anyone has a chassis-mount 9-pin mini-DIN socket in
their spares box, that'll do just as well (the A3000 has pads on the
motherboard for an 'alternate' mouse port.. I just need the connector)
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
http://ahefner.livejournal.com/20528.html
Writing a demo for the Nintendo Entertainment System (6502 CPU at 1.79
MHz, 2 Kilobytes of RAM for the CPU, 2 Kilobytes of RAM for the PPU
(video)) - in Common Lisp.
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884
On 2012-02-07 14.03, Cameron Kaiser<spectre at floodgap.com> wrote:
>
>> > So, does anyone have a record for oldest or weakest computer running Unix?
>> > The Z80 definitely did it. Maybe the 8080 could. I don't think the PDP-8
>> > could. I've been trying to figure out if the PDP-8 could handle C, and
>> > the answers I get range from "I don't know" to "Definitely not".
>> > Something I'd really like to see is a Z-machine running on the PDP-8.
> A while back I asked about PDP-8 Unices. I don't remember any replies, though
> I seem to remember some existed.
I very much doubt Unix ever could run on a PDP-8. The biggest reason
being the shortage of memory.
However, C have nothing to do with this question, as Unix was not
written in C initially. I suspect the answer to the question could be
the PDP-7, on which Unix was initially implemented (in assembler).
However, many would probably hardly recognize it as Unix by todays
standards. Unix was rewritten in C after it had moved to the PDP-11.
The PDP-7 was an 18-bit machine, so memory space was somewhat acceptable.
The original PDP-11 didn't have an MMU, and Unix on that was probably a
tight fit, as well as being somewhat restricted.
Johnny
If you would like the opportunity to build your very own Elf 2000,
please join the waiting list! If enough people join Bob might make up
another batch!
Scroll down to the bottom of this webpage to where it says "Sold Out!"
and then click on the "Join the waiting list" link below it:
http://www.sparetimegizmos.com/Hardware/Elf2K.htm
-- Quinn
I've got a board out of an old microwave oven here that I'm curious
about. There are two ICs on the board--an MP1009ANLP (28 pin 0.600"
wide DIP), which appears to be a TMS1000 MCU. I know that it's
factory-programmed and PMOS (-15V Vdd), and that's a lost cause since
I don't know what's in the ROM and there's no way to find out.
However, there's one other DIP on the board--a 14 pin SN99324. I'm
not certain, but it appears to be part of the LED driver circuitry (7
segment+decimal).
Does anyone have a clue as to what a SN99324 is?
--Chuck
Here's something neat: the VCF East 8.0 t-shirt art is being designed by
George Beker, who did all the robot art for Creative Computing magazine
and their "BASIC Computer Games" books. He's drawing a special "VCF Bot"
for us -- and the ONLY way to get one is to attend the show.
I recently acquired a Zenith/Heathkit Z-100. I almost didn't buy it because I have a number of S-100 bus systems, including an Intel 8080. But I was curious about its "dual processor" capabilities. So pack-rat that I am, I bought it.
Here's the process I followed in my restoration:
I checked out Herb Johnson's website which has a lot of good information on this system (http://www.retrotechnology.com/herbs_stuff/z100.html). I especially checked out his description of how to strip a Z-100 down to its motherboard (http://www.retrotechnology.com/restore/z_repair.html).
I did just that - removed the floppy disk and hard disk unit from the Z-100. I then removed the outer case and keyboard. Next came the video board. I also removed the Floppy Disk controller and the Hard Disk controller from the S-100 bus on the motherboard. Next I disconnected the power connections from the motherboard and removed the keyboard and found the foam mounting material gooey and disintegrating (not unusual for vintage systems). Finally I removed the video controller from the motherboard.
Stripping the system gave me the opportunity to check out the motherboard - both in terms of integrity and making sure that all the chips (which are socketed) were seated correctly. It also allowed me to document all of the jumper and switch settings on the motherboard.
I found that the motherboard had been upgraded to the full 786KB of RAM. I examined the video daughter card - and found it had the full 64K of video RAM. I also found that the motherboard had been upgraded with a "UCI - ZSM 8Mhz" daughter card. I also noted that U146 had been modified with a 74L257 "stacked" on top of whatever chip was originally there. I have no Idea what that was for (if any of you do, please let me know!).
I cleaned up the gooey foam and installed some Scotch two sided foam to replace it. I then put a dummy load on the power supply (switching supplies "like" loads). I used an old disk drive for the load (which I didn't care if it got destroyed by an aberrant voltage). I powered the system on - and the disk drive came up normally. I checked out all the power supply voltages: +16 was +15.98; +8 was +7.75; -16 was -16; +5 was +5.01 with 2mv of AC; +12 was 11.82 with 7mv of AC.
Given these good readings, I was ready to re-install all the systems components - which I did. (BTW, while I was disassembling the system, I had made extensive notes on what cables went where, etc., so putting it back together was an easy task.)
I then cleaned the contacts of the S-100 Floppy Disk Controller and Hard Disk Controller with DeoxIT Gold (formerly ProGold). I've found the stuff is terrific in making sure contacts have great conductivity - and stay that way. I then re-inserted both into the S-100 bus.
I connected a video monitor to the system - turned it on - and then powered up the system. To my great (and pleasant) surprise, the screen indicated that the system tried to boot but found a hardware problem. Fortunately, the system's ROM has a number of built-in diagnostics. The "startup" diags passed, as did the memory and keyboard. However, the HDD could not be read. Before I jumped to the conclusion that the HDD was bad (it was spinning happily) - I decided to re-check my re-cabling. Sure enough, I had forgot to re-attach a power connector to the HDD separator board.
After fixing my goof, I power up the system again - and to my super pleasure, it booted up to a prompt!
I had hoped it would be CP/M - but instead it was Zenith DOS 2.11. I've played with the system a bit - including testing out the floppy disk drive - and backing up the DOS system. Everything seems to work well.
Here's the Z-100's hardware configuration:
Dual CPU 8085, 8088
RAM 768K
Video RAM 64K, Color
HDD 10MB
FDD 320K (double side, dual density)
8MHz upgrade
Cheers,
Lyle
--
Lyle Bickley, AF6WS
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
