test-drb August 2004

test-drb@ccmp.vtda.org

283 participants
661 discussions

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

by dave04a＠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

22 years

Pile of Mac IIFX

by mkmizote＠raytheon.com

Hello, Do you still have that pile of Mac IIFX's. We may be interested in them if they still work. Thanks. Mike

22 years

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Antonio Carlini" <a.carlini(a)ntlworld.com> > >> The necessity of CRC's depend on what you plan on doing with the data. >> If it is just going to be sitting in a nice, safe box, then >> it doesn't >> matter. > >True. Unless you've gone to the trouble of archiving the >stuff because you would like it to be reliably retrievable >at some point in the future. > >If reliable retrieval in the future is of no concern, >then I propose a format conisting of an empty file. >At least you'll be certain of what you get :-) > >Seriously, after all the discussion of bit-rot on >various media, how can you consider some sort of >checksum to be anything other than essential? > >Some sort of error-correcting code might be an >even better idea. > >Antonio > > Hi Part of the problem here is that if the file containing the archive had any bit rot, most systems designed to read that media would simply fail to read the information. In many cases, it might not even be possible to read the CRC after the error occured. For error correction, one must also realize that one can only correct a single burst of errors that is smaller than a size specified by the correction method. Most of these can at least detect any single bit error. I have been known to recover data from cassette tapes by simply recording all of the data that comes out and modifying the data after the error. In my case, it was machester encoded and, by flipping and shifting the data, I was able to determine the size of the missing data. In some cases, the check sum was used to replace the missing bits. Still, in this case, I was able to bypass the normal code that read the media. I'm not against putting CRC's in, I'm just stating that there are limitations to its usefulness if something is lost other than to detect the loss. To keep from losing things still takes full redundency. Dwight

22 years

Let's develop an open-source media archive standard

by melamy＠earthlink.net

you have to think beyond emulators and think of just getting the data. You started this whole thing out by asking for ideas and concepts to make sure that disks could be made in years to come. I challenge you to expand the horizon and suggest that what you need is a way to get the data out easily and make disks. Personally, I have zero use for a image file format that can only be used to make disks and makes getting data out of it a pain in the backside. Maybe in years, I will need to make a floppy disk, but I believe that getting the data out (files or whatever you choose to call them) is more important and will be that way in the future also. Where small things can get lost, having a "standard" image file format that let's me do both makes more sense to me. As for emulators, Microfast by Simeon Cran uses an import from ms-dos and the emulator runs great. The original BabyBlue card wrapped the cp/m program in a ms-dos wrapper and then you didn't even have to think twice about running a compiler, linker, etc. Would it do direct disk access? No, but that is what the original platforms are for. Most programs went through the OS for disk access because they were file oriented. I can't recall how Fred arranged his emulator, but I have a copy of that to. Your arguement about emulator programmers wondering "why" about binary is a non-issue. The spec defines ascii and that is the way data is represented. They will probably more appreciate the the standard then complaining about such things. If they do, then they certainly don't need to write anything. A user could easily write the utility or someone who is part of the standards group will make software templates and simple utilities available. Writing the utilities would be something that I wouldn't mind helping with for example. The image file that you are discussing is only good as a "how to" to write arbitrary data to arbitrary media. It is only good for creating a final media image because the format being contemplated (mixing data into the physical spec) will preclude the file from standing on its own. I was proposing identifying data blocks as files if that is what they were. The data blocks would have been sequential and trivial to retrieve. That is hardly what I would call defining a file system as part of the image file. best regards, Steve Thatcher Original Message: ----------------- From: Vintage Computer Festival vcf(a)siconic.com Date: Thu, 12 Aug 2004 10:25:20 -0700 (PDT) To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Steve Thatcher wrote: > what is wrong with making things easier? If a small amount of effort > could be put out to make the image file have a more useful purpose then > to ONLY be able to create media, why not? Your view seems to be to make > all the emulators tyhat are currently available not work anymore because > now they have to be modified to access an image file. My idea is to not Steve, All emulators for 8-bit machines today that I'm aware of use disk images. Emulators like SIMH can read in individual files by, for instance, turning the file into a virtual paper tape reader. Your point, again, is taken, but so is Dwight's. I think it depends on what emulators you spend most of your time playing with which defines your outlook on this. One problem I did think of after I sent my last message concerning this is that if you do start including filesystems, people (probably emulator writers in particular) will start to wonder why you didn't store the data in binary. "Why," they ask, "do I have to convert the data from ASCII when the file is fully capable of holding binary data?" Then you might get some joker making unauthorized extensions to the spec with binary data fields. Perhaps I'm getting carried away here, but I do see this as potentially problematic. > If you thought of an emulator is to BE the machine in absolutely all > respects then yes who ever is writing it needs to understand the file > structure intimately and we need to add even more to the specification > to allow writing to an image file... Isn't the specification itself a "how to" for writing an image file? Also, the image file we are discussing is *NOT*, again, intended to serve the emulators. Emulator usage is a SECONDARY concern. -- Sellam Ismail Vintage Computer Festival ---------------------------------------------------------------------------- -- International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ] -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

22 years

MC670P ICs

by psmith＠fox19.com

Tim, I just saw your e-gram stating you had some MC679P ICs. Is there any chance you still have them? I have some ancient equipment that uses this "coal fired logic" and I recently blew up some chips. Paul K Smith Chief Engineer WXIX-TV (513) 562-2428

22 years

Let's develop an open-source media archive standard

by RCini＠congressfinancial.com

This example represents the block data using metatags...I guess along the "XML" part of the thread. I was thinking similarly to you but not using XML metadata: ;Hardware descriptor MFGR MACHINE SUBTYPE DRIVETYPE (this of course defines what follows) ;for floppy DRIVESIZE ENCODING TRACKS SECTORS SECTSIZE ;HexData ; Each record or group of records contains the related media data. The address record would be used for encoding the metadata 00TTSSHH: (00-track-sector-head) I looked to Intel Hex (or Motorola) because it had built-in CRC facilities and it was human-readable ASCII. The drive and machine description could be encoded in special MOT records probably. XML is more a more "current" technology but I was trying to keep with the platform neutrality by sticking to text-only and not assuming the use of any other technology like XML. Rich -----Original Message----- From: cctalk-bounces(a)classiccmp.org [mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer Festival Sent: Wednesday, August 11, 2004 1:56 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: Let's develop an open-source media archive standard On Wed, 11 Aug 2004, Cini, Richard wrote: > I might have missed what the ultimate use of this archive would be. Will the > archive be used to (1) re-generate original media; (2) operate with > emualtors; (3) both? Both. Emulators will certainly be able to make use of the archive by having parsers built-in that can translate the archive data into something the emulator can use. So instead of point the emulator to a binary disk image, you would point it to an archive file and it would translate the file back into tracks/sectors, or punch cards, or whatever. > To ensure integrity of the data I would propose recording the data in the > Intel Hex format -- it's text-based and has built-in CRC. Now, we'd have to > modify the standard format a bit to accommodate a larger address space and > to add some sort of standardized header (a "Hardware Descriptor"). This data > would be used by the de-archiver to interpret the stream of data read from > the data area (the "Hex Block"). I think you're thinking of this in terms of a large binary file encoded as ASCII hex. If so, this is not what's being proposed. What is being discussed is a format which actually describes the physical medium. For example, on floppy: <MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE FORMAT=GCR TRACKS=35 SECTORS=16 SECTORSIZE=256> <VOLUME>Apple ][ System Disk</VOLUME> </MEDIA> <DATA> <TRACK 0><SECTOR 0> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0 </SECTOR></TRACK> ... <TRACK 34><SECTOR 15> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15 </SECTOR></TRACK> </DATA> > I think that we should start compiling a list of the various media we want > represented and how that media is organized natively. I don't mean "well, it > has blocks and sectors" either. We should examine the exact format down to > the actual numbers (i.e., "2048 blocks of 256-bytes recorded twice"). Seeing > how the various data stores are organized should bring some clarity to how > we should represent it. I agree. This would be useful. Does someone want to volunteer to do this? -- Sellam Ismail Vintage Computer Festival ---------------------------------------------------------------------------- -- International Man of Intrigue and Danger http://www.vintage.org [ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] [ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]

22 years

Old stuff

by HB＠kpll.dk

Hi, I assume you have left the B26 platform for a long time ago. But what you had in your hand was a excellent machine, with no comparison at that time, think about running multitasking on an 80186 platform, no one else, as far I know, has done that. You can not boot on any DOS/Windows disks, you have to have an B26 operating system, the prompt V 9.2 B,D,L,M,P,T:_ is at debug level, you can choose here to boot on varios sources, but again you need an old BTOS/CTOS os I did work for Burroughs-Unisys- and a Unisys consultant company at that time working primary with BTOS/CTOS. Best regards / Med venlig hilsen Henrik Bigum IT-Consultant KPLL Pilestr?de 65 1112 K?benhavn K e-mail hb(a)kpll.dk Phone +4533744100 Fax +4533744001

22 years

Let's develop an open-source media archive standard

by melamy＠earthlink.net

what is wrong with making things easier? If a small amount of effort could be put out to make the image file have a more useful purpose then to ONLY be able to create media, why not? Your view seems to be to make all the emulators tyhat are currently available not work anymore because now they have to be modified to access an image file. My idea is to not change all that, make the image file simple enough to extract data. I really believe that to not do that simple thing will make the project less than what it could have been. I am not proposing something that takes a lot of code, but rather let's us do things simpler. Maybe you need to define what an emulator is so I can understand why you think being able to access data easily should not be done. If you thought of an emulator is to BE the machine in absolutely all respects then yes who ever is writing it needs to understand the file structure intimately and we need to add even more to the specification to allow writing to an image file... If you are designing an emulator to look like a front panel and run cp/m programs from you favorite stash, then having to design a complicated file structure interface to an image file is not needed. best regards, Steve Thatcher From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 11, 2004 3:24 PM To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard >From: "Steve Thatcher" <melamy(a)earthlink.net> > > >I realize that the idea is to create a format to make re-creation >of media possible for a variety of platforms. We can certainly do >that and have its only function be to maintain a physical data format. >My added idea is that the data and the formatting be separated so >that a simple utility on a non-target platform could extract data >from the image file. > >If we create a physical description only and do not abstract the data >then any emulator must understand the OS file structure in order to >retrieve any internal file representation. My idea would make the >file re-creation simple in that the xml image file would be parsed >for the actual file data that an emulator would need. This makes >the emulator easier. No, this is to archive the disk, not to make life easy for emulators. Again, you assume that the data is files. Also, anyone making such an emulator will surely know how to find files ( if they exist ) in an image of the disk. Most emulators include the BIOS and such. The emulator that we have in the H8 group simply uses the BIOS code and the boot code from the disk to find file ( as it should ). It just needs raw data. The emulator I/O is just tracks and sectors, not files. >To retrieve a file from the physical layout that it at the end of this >message, >the emulator must know the actual disk format that is used on >the target system (the one the image file was made for). I have seen >cp/m systems where the actual physical sectors were sequential on disk >and the OS file sector was actually virtual to increase speed. Not my >idea of the way to do it. It is much easier to make the physical >sectors slewed so that a physical sector is a file sector. These >are the types of issues you will have to overcome if an emulator >must totally understand each and every file system for a cp/m >version for example. Like I said, the archive file can include sufficient information to extract the data in any form that you'd like but it must as a minimum be able to recreate the physical disk. It may take some human to actually make the physical media generator but the data in the file should be sufficient to do that. This is not an easy task and goes beyond simply finding files in the raw data. Dwight > >Sellam, let me know if you would like to discuss this via telephone > so I can convery the idea that I am proposing. > >best regards, Steve Thatcher > >-----Original Message----- >From: Vintage Computer Festival <vcf(a)siconic.com> >Sent: Aug 11, 2004 3:00 PM >To: Steve Thatcher <melamy(a)earthlink.net>, > "General Discussion: On-Topic and Off-Topic Posts" <cctalk(a)classiccmp.org> >Subject: RE: Let's develop an open-source media archive standard > >On Wed, 11 Aug 2004, Steve Thatcher wrote: > >> I agree with Sellam on the point about using it both for media >> re-creation and emulation. The trouble with the approach below of just >> using raw data on a track sector basis is that now you have created a >> file that can only be used with an emulator that understands the >> physical format and OS access for the computer system you are emulating. > >That is the point, really. What we are attempting to do is describe as >faithfully as possible a physical media with logical data in a purely >logical form. The goal would be that the physical media could be >re-created from the imagefile if need be. The parameters of the physcial >media are specified so that this can be possible. > >> My earlier point of separating the data and the format information >> allows a single file (that would not be much bigger that the one >> described below) to contain multiple platform specific files that can be >> "read" by a simple utility that does not require any knowledge of the OS >> or the platform. > >I'm not quite understanding you here. Or maybe I am. An image in the >format shown below could be read by any emulator. Making sense of the >data with respect to that emulator is a different issue altogether, but it >does make it possible for, say, a Northstar Horizon emulator to load up an >Apple ][ disk image and then try to access it. > >Anyway, I don't think I am quite getting the point you are trying to make. > > >> <MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE FORMAT=GCR TRACKS=35 >> SECTORS=16 SECTORSIZE=256> >> >> <VOLUME>Apple ][ System Disk</VOLUME> >> >> </MEDIA> >> >> >> <DATA> >> <TRACK 0><SECTOR 0> >> >> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0 >> >> </SECTOR></TRACK> >> >> ... >> >> <TRACK 34><SECTOR 15> >> >> HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15 >> >> </SECTOR></TRACK> >> </DATA> > >-- > >Sellam Ismail Vintage Computer Festival >------------------------------------------------------------------------------ >International Man of Intrigue and Danger http://www.vintage.org > >[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ] >[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ] > > >

22 years

Searching for SunOS 4.1.3

by mross666＠hotmail.com

>I am looking for a copy of SunOS 4.1.3, preferably version C. Your wish is my command: http://www.corestore.org/solaris1.1.2.zip Download, unzip, burn the enclosed ISO image. Bootable CD. I (and some of my Xerox Buddies) had exactly the same problem trying to ressurect Xerox GVX - the Xerox Mesa/Viewpoint emulator (in effect) for X. Wanted a very particular version of SunOS (think it also runs on AIX but don't quote me on that). (If anyone wants to play with this stuff, you can also grab http://www.corestore.org/GVXv1_0.zip - or http://www.corestore.org/gvwin21.zip for the M$ windoze version - win 9x *only*) Mike http://www.corestore.org

22 years

TKQ50 proms

by Adrian＠beovax.co.uk

Yeah, I saw that somewhere in amongst the other 530 messages I downloaded yesterday :) > -----Original Message----- > From: cctalk-bounces(a)classiccmp.org > [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Pete Turnbull > Sent: 13 August 2004 10:48 > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: TKQ50 proms > > > On Aug 12 2004, 20:23, Witchy wrote: > > > -----Original Message----- > > > From: cctalk-bounces(a)classiccmp.org > > > [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Pete Turnbull > > > > I'm looking for ROMs (or ROM images would be better) for a TQK50 > > > controller. The ROMs I want are 23-330E5 and 23-331E5. > Can anyone > > > help? > > > > Yep, I'm sure we've got a TQK50 on the shelves in stores; I can pull > it > > and dump the ROMs for you. > > Thanks, but I've now got several copies of both sets of TQK50 > ROMs (23-248E5/23-249E5 and 23-330E5/23-331E5). > > I did mail the list to say I had them now, but perhaps it got > lost amongst the archive messages :-) > > -- > Pete Peter Turnbull > Network Manager > University of York >

22 years

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

Jump to page:

2026

2025

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