test-drb August 2004

test-drb@ccmp.vtda.org

283 participants
661 discussions

Xerox Alto Restoration + Emulation (Mike Ross)

by mross666＠hotmail.com

>>the McMasterUniv/KevinStumpf PDP-15 several years ago. >How is Kevin.S lately? I got the impression that he was one of the older >collectors looking to get out of the hobby, or at least lower the >collection >by an order of magnitude. I bought from him a sys/370-168 control panel. >The guy was definitely into big stuff. He's pretty much out of the hobby, I believe. I think the stuff I got from him was pretty much the last. He's pursing other interests, AFAIK. Mike http://www.corestore.org

20 years, 4 months

Custom made front panels

by rcini＠optonline.net

Mike: I've prototyped (and Scott has refined) a replacement Altair 8800 front panel with this service. $98 for single units dropping to the low-$80's. I haven't ordered samples yet but if I get the front panel attachment for the Altair32 Emulator done, I will. Rich ----- Original Message ----- From: Michael Holley <swtpc6800(a)comcast.net> Date: Friday, August 13, 2004 11:38 pm Subject: Custom made front panels > When I restored my TV Typewriters I made a metal case. I was > looking for a > good way to label the back panel. I found an online source for > engravedpanels. FrontPanelExpress provides free design software > (Windows only) and > very reasonable prices. > www.frontpanelexpress.com > > I ordered a 4.5 by 13.5 inch panel with punched holes for a DB25 > connector,switches and fuseholder. It was anodize aluminum with in- > filled lettering. > The cost for one was $46 plus shipping. I have a write-up here. > http://www.swtpc.com/mholley/CT_1024/Restore/BackPanel.htm > > Michael Holley > www.swtpc.com/mholley > > >

20 years, 4 months

Anybody have $35K to $89K to spend...

by rmeenaks＠olf.com

Aladdin 4D is now on ebay (with source and full rights): http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=2992&item=3693574489& rd=1&ssPageName=WDVW I contacted the guy asking about the transputer port (the Amiga Warp boards) but he only said it was a contracted item. Also asked who did the port so that I could contact them, but he wouldn't say. Anyone here know???? Thanks, Ram

20 years, 4 months

8" floppy drives

by Gianmario.Scotti＠nokia.com

Hello, I know this is a long shot, but I can try: do you still have any of those 8" floppy drives you mentioned in classiccmp.org newsgroup? thanks in advance mario

20 years, 4 months

PET problem SOLVED!

by pete＠dunnington.u-net.com

On Aug 13 2004, 22:07, Dave Dunfield wrote: > Ethan, Dwight (and anyone else who helped), > > Thanks for all the help - I've solved it and it works! > > Turns out it was NOT the ROM's -- After my last post I got to thinking that the PET > ROM's are probably fused type, and wouldn't go marginal like an EPROM They're masked ROMs, not fusible-link types. Even fusible-link ROMs can occasionally go bad, though less often and more slowly than EPROMs. Sometimes the fuses "grow back" by diffusion. -- Pete Peter Turnbull Network Manager University of York

20 years, 4 months

Tandy

by tyger69＠chartermi.net

Someone said: Tandy was trying to peddle some "business" "mini-computer"s. IIRC, it was built into a desk. I don't know where you had to go to actually SEE one (I don't think that even the Radio Shack "computer center"s had them), but Tandy did have a catalog for them. Yup! That's the animal, all right...built into a desk. I can post the picture on a webpage if anyone is interested in eyeballin' it. --T Jam the computer...trash every lethal machine in the land! -- Timothy Leary

20 years, 4 months

PET startup sequence?? (was LF: Commodore PET schematics, troubleshooting info)

by dwight.elvey＠amd.com

Hi If I understand you right, there is a RAM test. Place this same code in low RAM ( assuming it test going up ) with the initial value such that it doesn't overwrite your code. If it hanges, it is something that it is talking to. If it hanges, the ROM problem is likely. You migh also look at changing the PS voltage slightly. Rasing the voltage by 3% should not cause any failures but if it starts to work, it is an indication. Dwight >From: "Dave Dunfield" <dave04a(a)dunfield.com> > >A little more progress... > >Here is the BASIC startup code, which is jumped to by the kernel (in F000 ROM) if DIAG is >not pulled low (Basically, it goes either here or the monitor): > >; initcz Initialize BASIC RAM > D3B6 iD3B6 LDX #$FB > D3B8 TXS > D3B9 LDA #$4C > D3BB STA $51 > D3BD STA $00 ; USR Function Jump Instr (4C) > D3BF LDA #$73 > D3C1 LDY #$C3 > D3C3 STA $01 ; USR Address [4: C373] > D3C5 STY $02 > D3C7 LDX #$1C > D3C9 iD3C9 LDA $D398,X > D3CC STA $6F,X > D3CE DEX > D3CF BNE $D3C9 > D3D1 LDA #$03 > D3D3 STA $50 > D3D5 TXA > D3D6 STA $65 ; Floating -accum. #1: Overflow Digit > D3D8 STA $10 ; 3: width of source (unused - from TTY) > D3DA STA $15 > D3DC STA $0D ; 3: Flag to suppress PRINT or PRINT# > D3DE PHA > D3DF INX > D3E0 STX $01FD > D3E3 STX $01FC > D3E6 LDX #$16 > D3E8 STX $13 ; Pointer Temporary String > D3EA LDY #$04 > D3EC STA $28 ; Pointer: Start of BASIC Text [0401] > D3EE STY $29 > D3F0 STA $11 ; Temp: Integer Value > D3F2 STY $12 > D3F4 TAY > D3F5 LDA #$80 > D3F7 BNE $D400 > D3F9 LDA #$00 > D3FB LDY #$B0 > D3FD JMP $D41B > D400 iD400 INC $11 ; Temp: Integer Value > D402 BNE $D408 > D404 INC $12 > D406 BMI $D417 ; initms Output Power-Up Message > D408 iD408 LDA #$55 > D40A STA ($11),Y ; Temp: Integer Value > D40C CMP ($11),Y ; Temp: Integer Value > D40E BNE $D417 ; initms Output Power-Up Message > D410 ASL > D411 STA ($11),Y ; Temp: Integer Value > D413 CMP ($11),Y ; Temp: Integer Value > D415 BEQ $D400 > >; initms Output Power-Up Message > D417 iD417 LDA $11 ; Temp: Integer Value > > >On the working PET, I can use 'G D3B6' and it starts BASIC, just as if it >were running normally. On the bad PET, it hangs, and never prints the message >which is output by the very next block (D417). > >[Interesting side note - this NEVER produces the startup "noise", so it is >clearly not produced by BASIC either ... a mystery] > >Now, on the bad pet, if I do 'G D417', which bypasses this block of code, >it issues the startup message and comes up in BASIC (somewhat weird because >various things were not setup, but it's there). > >So - thats pretty conclusive proof that this is the block where the problem >is manifesting itself. > >Looking at the block of code, it "shouldn't" hang ... There are only two >loops, the first is counted by a register (as long as the CPU is good this >should work, and I have swapped the 6502 with the other machine) ... the >second goes until RAM fails to verify (this will definately happen by the >time it reaches the ROM), or the $11,$12 location wraps to a negative >value (32k max RAM). There are no subroutine calls in this block, so it >should not depend on a valid stack. > >Using my "try BASIC then reset to monitor without interrupting power" >technique, I see that $11,$12 almost always contains $01,$40, which means >that it reached the INC $11 once (first time through). > >The only way I can see this loop crashing is if the $11 (or $12) location >does no increment correctly (RAM fauly) - I've manually tested all kinds of >values in them, or if the ROM "goes bad" during code execution. > >[If the $12 location was faulty, I should see "random" values in $11 depending >on the timing of when I hit reset] > >I'm thinking ROM again (this was my "gut feel" when I started because I have >seen so many PET ROM's go bad) - although it reads OK in my EPROM programmer, >and also this block dumps correctly from the monitor, both of these accesses >are fairly laid back - hitting the code is the first time we execute code from >this device... Timing on execute could be tighter (I haven't checked the >databook yet), also the frequency of accesses will be much higher ... Perhaps >if the ROM is marginal, one of these factors is enough to cause a failure. > >I think a bad ROM is more likely than a single location in the RAM appearing >to work for manual tests, but failing during this particular block of code, >especially considering that the rest of RAM is good enough for lots of other >stuff to run ... > >What do you guys think? Anyone have experiences with marginal PET roms? > >Regards, >Dave > >-- >dave04a (at) Dave Dunfield >dunfield (dot) Firmware development services & tools: www.dunfield.com >com Vintage computing equipment collector. > http://www.parse.com/~ddunfield/museum/index.html > > >

20 years, 4 months

PET startup sequence?? (was LF: Commodore PET schematics, troubleshooting info)

by dave04a＠dunfield.com

>Hi Dave > It still sounds like a RAM related issue. The 6502's >needed to gate the VMA with Phase2 ( as I recall ) to >get clean address selects. You might put a scope on >this circuit and make sure it looks like it is working >well. > You should try to create a more exhaustive RAM test. >Although, time consuming, GALPAT is just about the >most intensive. >Dwight Hi Dwight, I've checked all the RAM signals - everything looks OK (about the same as the other unit). I tried putting my diagnostic jumper on both the other (working) SP9000 and the PET 4032 that I have here, and both of them exhibit the same problems with getting the monitor up and running - so I think those issues are just a red herring and are not realated to the actual fault. (For some reason, entering 'M 6666' seems to cause a "break" which comes back with SP=FF and from then on it works OK - on all three machines). I haven't seen a RAM error yet in my poking around (and I've done a fair bit), however there could be address bus errors etc. which I would not see. I really wish I had a better way to load code into the machine then through the keyboard - I may still do up a RAM test replacement for the kernel ROM. (Which is a big job, since I don't have a plug-in replacement for the 2332 so I need to make up an adapter etc.) Has anyone created a "virtual" tape deck? - The monitor has commands to load and save memory from/to tape... I'm still trying to fathom what exactly is happening at power-up - I can't explain the timing of the "beep" - I thought it might bave been generated by the interrupt, however with pin4 physically pulled out and tied high (no IRQ) the beep still happens... I think the key to understanding what is going on is to figure out exactly where it's hanging during the initialization of BASIC. Btw, if I hit 'X' at the monitor prompt, I do get the BASIC 'READY' prompt, although you can't do anything due to the fact that in this case, BASIC never got initialized ... Same thing happens on the other machines. Argh... this is turning into a bigger job than I had expected (It's a lot easier when things don't work at all) ... I want to get these d*mn things off my bench - I acquired a 5100 earlier this week which is has been calling to me ever since I brought it home. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html

20 years, 4 months

PET startup sequence?? (was LF: Commodore PET schematics,troubleshooting info)

by dave04a＠dunfield.com

Hi Ethan, Thanks again for the very useful information. I've had some success - but now have more questions than answers. Reminder: This SuperPET 9000 has been stripped to just the 6502 board. On power-up it init's screen (can see garbage, then clear), plays the "bee-dle-bee-dle-bee-dle" startup noise, then hangs with the blank screen (never displays basic startup message). Some experimentation suggests the it continues to run code at this point (ie: is hung waiting for something), however this is by no means certain. I hunted around funet and found the Basic4 ROM disassembly - as far as I can tell, it exactly matches the ROMs in this PET. Looking at the startup code ($FD16), and the schematic, I was able to identify the diagnostic input signal (Pin 5 of user port), and when held low, it DOES startup in the monitor (Took me a long time to figure out the commands - especially the fact that you need TWO spaces after ':' to write to memory). Now is where things get interesting. The monitor always starts up, and the 'R' always works, however 'M' to display memory causes it to crash about 80% of the time - however if it works, it is reliable, and 'M' will continue to work until the next time I restart the machine. Even 'M xxxx' (no second address which normally never outputs anything anyway) will fail. Depending on the value of 'xxxx', it will either crash (hang), or more often re-enter the monitor with 'B*' indicating it thinks a breakpoint went off (not suprising if the stack is corrupt - read on). At first I thought this might be an indication of bad RAM (still might be), however after playing with it for a while, I noticed that the SP in the register display is always '01', '03' or some low value when it doesn't work - I'm guessing the monitor tries to locate it's stack below here and it wraps) - sometimes SP shows up as FF or FE, and then all works fine. I have no idea how this is (not) getting initialized on power-up entry to the monitor through the diag signal (any idea)? Once it "works", I can read and write RAM and it appears to be holding the values (although by no means an exhaustive test). Another thing I don't understand yet: When powered-up with diag held low, the system goes directly into the monitor ($D472), and DOES NOT play the "bee-dle-bee-dle..." startup noise. This indicates that this noise should be generated by entry into BASIC ($D3B6). Looking at this code, it sets up a few location in zero pages, and then output the startup message (no other subs are called in between) - I see nothing which would generate the "noise" - so one would think it is being generated AFTER the startup message, however ... When I start the machine with DIAG high (normal), I see screenful of garbage (briefly) and then it clears, then the "noise" plays - no message comes out, but I know the screen is working. Referring to the working machine, it is clear that the "noise" finishes BEFORE the text comes out, however I don't see where it could be generated. The only function called before the message is output is $E000 to setup the I/O, however it is called before DIAG is tested (ie: even if entering the monitor), and the noise is not heard in this case... By using a reset switch, I was able (after several attempts) to bring the machine up from power off in "normal" mode, and then pull DIAG low and reset to enter the monitor and examine the RAM - comparing the values in ZPAGE to those written by the BASIC init code, I can confirm that the code just before the message is output is in fact executing... Any further ideas? Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Vintage computing equipment collector. http://www.parse.com/~ddunfield/museum/index.html

20 years, 4 months

Introduction

by jwstephens＠msm.umr.edu

nice page of systems, especially the core one. Was the photo of your system, or taken from the book? user anonymous wrote: > I have been on this list for about a month now. Very interesting how many people still play around with this old stuff. I have a few pictures of some of my old computers and peripherals for those interested. > > http://www.dickey.intell-a-sys.com/collect.html > > Most are my original systems and have some interesting peripherals attached. I have a few other computers that I am still rebuilding. I have not worked on them in a while, but reading all your mail may ignite that spark. Too many hobbies. > > Well, just thought I would introduce myself.

20 years, 4 months

← Newer
1
...
29
30
31
32
33
34
35
...
67
Older →

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