test-drb February 2012

test-drb@ccmp.vtda.org

158 participants
158 discussions

by bqt＠softjar.se

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

12 years, 2 months

VAX for running old version of VMS

by cctech＠beyondthepale.ie

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.

12 years, 2 months

WTD: Acorn or similar 3-button quadrature mouse

by classiccmp＠philpem.me.uk

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/

12 years, 2 months

Fun with Lisp: Programming the NES

by lproven＠gmail.com

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

12 years, 2 months

PDP-8 Unix

by bqt＠softjar.se

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

12 years, 2 months

Does anyone want to buy an Elf 2000 ???

by popeye＠p-t-b.com

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

12 years, 2 months

[blog] Recent Additions to BitSavers

by legalize＠xmission.com

Based on our recent discussion of ISC and Intecolor terminals and noticing some recent additions to BitSavers prompted me to write this blog post for the Computer Graphics Museum blog: <http://computergraphicsmuseum.org/2012/02/07/recent-additions-to-bitsavers/> -- "The Direct3D Graphics Pipeline" -- DirectX 9 version available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

12 years, 2 months

Unknown IC on a TMS1000 board

by cclist＠sydex.com

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

12 years, 3 months

VCF East t-shirt news ....

by evan＠snarc.net

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.

12 years, 3 months

Restoration of a Zenith/Heathkit Z-100

by lbickley＠bickleywest.com

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"

12 years, 3 months

Jump to page:

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