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

Thanks for the very useful information! >If you want the keyboard to work, you'll need to set up one of the 6520s. If >you just want to see stuff on the screen, there's a table in the ROMs that is >loaded into the 6545 CTRC. There are two sets of values, one for 4032 and one >for 8032 (different ROMs). The other chips are used for IEEE-488, cassette >control, and the user port. No initialization for your purposes required AFAIK. I checked the funet archive and found some details, however the PET "IO" document describes only the 6520's and 6522 - there is no mention of the video controller. The only other references I found to I/O addresses were obviously a disassembley, with such meaningful labels as: AE810 DS 1 AE811 DS 1 AE812 DS 1 Can you tell me where (address) the 6545 is located? I'm going to begin disassembling the Kernel ROM and see if I can figure out enough to turn on the screen - don't need keyboard (yet) - just want to be able to display some info. >Once you extract the table and load the 6545, you should be able to sling >bytes at the screen starting at $8000. Remember that "POKE codes" are not >ASCII nor PETSCII, they are character codes from the chargen ROM (not >accessible to 6502 memory space). There should be some docs on this on funet. >As an example, though, while you might "PRINT CHR$(65)" to get an 'A' on the >screen, you'd "POKE 32768,1" to get that 'A' to appear in the upper left >corner of the screen. I didn't see an obvious reference - can you give me a pointer - all I really need right now is 0-9,A-F and SPACE - I can determine these by fooling with the working machine if I have to. Btw, do anyone have (or know of) a working stand-alone monitor program which can be stuffed into the Kernel ROM position? 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

19 years, 10 months

Let's develop an open-source media archive standard

by vcf＠siconic.com

Ok, instead of all the unproductive bickering over semantics (most of which is illogical...come on, admit it) I'd rather we actually discuss developing further an open-source, public domain, free (in every sense of the word) standard for archiving data media of all types (magentic, paper, or otherwise). This is basically going to be a continuation of what we've already discussed on the list, and what Hans and I have discussed in private. First, let's start with the goals. The format should be: 1) Well Documented (with such documentation actively preserved in all four corners of the globe and beyond) 2) Not constrained to any particular hardware 3) Be inclusive of all physical (and logical?) manner of recording media 4) Be implementable on even the simplest architectures (because the original media source will in many cases have to be read on the hardware it is connected to) 5) Open source, public domain, etc. (although a copyright may be held if it makes sense to do so) 6) Adaptable, expandable, revisable (for future extensions) 7) Text-based and storable in commonly accessible character formats (i.e. a suitable subset of Unicode, i.e. ASCII) 8) Allow for the representation of media in either logical or physical (raw bit stream) formats This is a good start. Someone please continue adding to the definition. I will establish a special session at the next VCF (November 6-7) where we can commence a committee for formalizing this standard and getting it recognized internationally in all the various relevant groups (i.e. ANSI or ISO/IEC). -- 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 ]

19 years, 10 months

Drive format spreadsheet questions

by zmerch＠30below.com

http://www.30below.com/~zmerch/classics/driveformats.html It's new, it's rough, it's mainly to figure out what kinds of data we need here -- right now, I can see that we need 2 spreadsheets; one for physical drive formats, and one for OS layouts. (and yes, it's evil HTML -> StarOffice 6.0 "saved as .html". I ain't goin' fer pretty yet... ;-) ) Believe me, I realize that it's not anywhere perfect... so I'm asking for more input for whatever (many things) I've forgotten to include. If you have info for different disk formats, please feel free to include them, but please be aware that they may not be integrated until the format is more solid. Jay, I dunno if the addresses are munged in the archives... so I'm going to err on the side of caution here. I have 1 mailing address that as yet gets no spam (so has no spam-filter), and its: {my Ham radio callsign} @30below.com. (If you wanna go the hard way to find it, go here: http://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp and search for "Merchberger" and look for my active one.) If not, I'll use the phonetic alphabet, hopefully spammers haven't figured that one out yet for the spiders: Alpha Bravo Ait Kilo Kilo That address gets very little email (unlike my main address which gets around 500 emails/day) so I'll see things quickly there... and also, the main email is personal/work/mailer-daemon/root/catchall/whatever and also has a spamfilter, so I might miss one email there. Rare, but it can (and unforch, does) happen. This way, guaranteed not to be missed in any way. ;-) Thanks, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | A new truth in advertising slogan sysadmin, Iceberg Computers | for MicroSoft: "We're not the oxy... zmerch(a)30below.com | ...in oxymoron!"

19 years, 10 months

RT-11 / PDP-11 Software Users

by jhfinexgs2＠compsys.to

The reason the subject is for "Software Users" is that ""Hardware Users" will probably want to use ONLY standard DEC distributions of RT-11 which sufficiently exercise the real PDP-11 hardware. The goal of this post is to reach and elicit comments from all of those hobby RT-11 Users who want the bugs fixed and / or want some enhancements. I suppose that it might even be possible that there are some commercial RT-11 users who might be interested, but at this point I am not aware of any and doubt very much that any commercial RT-11 users would be sufficiently interested. BUT, if you are still there, it might still be possible to accommodate the commercial side. The ISO file for a CD with 13 RT-11 distributions is available for download at: http://www.classiccmp.org/PDP-11/RT-11/dists/ The file is: RT11DV10.ISO.zip The CD contains 13 RT-11 distributions from V01-15 up to V05.03 under both the ISO9660 file structure along with 4 RT-11 directories for the 4 RT-11 partitions on the CD. A rather unique aspect of the CD is that none of the files in the ISO9660 file structure are duplicated. The RT-11 directory entries point to the same location on the CD for the same file in each case. In addition, if SIMH is able to ATTACH the CD as as single file, then it will be possible to actually BOOT the CD under RT-11. Otherwise, just BOOT the container file RT11DV10.ISO, after it is copied to the hard drive (UnZipped actually), under RT-11 as in: ATTACH RQ0: RT11DV10.ISO SET RQ0: LOCK BOOT RQ0: It is STRONGLY recommended that NO changes of any kind be made to the ISO file under RT-11, even by experienced RT-11 users. The reasons are explained in the 2 README files. NOTE that all of the images for the RK05 and RL02 media have been truncated - all of the contiguous blocks with zeros at the end of the file image have been removed. The primary reason was so that more of these file images would fit on each RT-11 partition. Specifically, since all RL02 file images are 20,450 blocks, ONLY 3 would fit on each RT-11 partition. In addition, even if the full image of 20,450 blocks were present, it would still not be possible to use each file as a correct file image in all situations under SIMH since the system area needed for the INITIALIZE command under RT-11 would NOT be present. IF the RT-11 user wishes to copy the truncated file image to a "fully functional" RL02 container file to be used under SIMH, then copy the file ZEROSDL.DSK at the end of the CD as in: C:\>COPY D:ZEROSDL.DSK C:RT11V5.03 C:\>PDP11 simh>ATTACH RL0: D:RTV5RL.03 simh>SET RL0: LOCK simh>ATTACH RL1: C:RT11V5.03 simh>BOOT RL0: COPY/DEVICE DL0: DL1: NOTE that the file ZEROSDL.DSK was created by using PUTR to: (C:\)>FORMAT ZEROSDL.DSK/RL02 A big thank you to John Wilson at: http://ww.dbit.com/pub/putr/ For those RT-11 users who have a legal license to run RT-11 under E11, there are two alternatives. If the user has a DVD drive or CDROM drive which allows the first 64 blocks (16 CD sectors) to be read under E11, the it is possible to MOUNT the complete CD as an image as in: E11>MOUNT DU0: CDROMD:/RONLY Of course, it is also possible use the actual ISO image file of the CD as in: E11>MOUNT DU0: C:RT11DV10.ISO/RONLY OR, if the files are on a CD and the user prefers: E11>MOUNT DL0: D:RTV5RL.03/RONLY Depending on the option that the user prefers, the complete text would be: C:\>COPY D:ZEROSDL.DSK C:RT11V5.03 C:\>E11 E11>MOUNT DU0: CDROMD:/RONLY E11>MOUNT DL1: C:RT11V5.03 E11>BOOT DU0: COPY/DEVICE/FILES DU0:RTV5RL.03 DL1: If anyone requires any help in using V1-0 of the CD, please ask!!!!!!!! MY BACKGROUND -------------- I am an RT-11 software addict. I don't know why, but maybe a partial answer is because I have OCB (Obsessive Compulsive Behaviour). In any case, I have used RT-11 off and on for almost 30 years (mostly ON) since I started with V02 of RT-11. I can't remember a single year, since, when I did not use RT-11 some of the time and some years I probably spent more than 4000 hours designing, writing and debugging RT-11 software. I am presently in the midst of fixing bugs and making some of the enhancements mentioned below. PURPOSE OF THIS POST ----------------------- This point is to ask if there are any RT-11 users, either active or inactive, who want to see any of the RT-11 bugs fixed along with enhancements added. While I believe that these news groups are the best means of making contact, perhaps others exist as well. PLEASE mention any other method of contacting RT-11 users. INDEED, PLEASE forward this message to them if you know of any other RT-11 users who may still be interested. LIST OF ITEMS TO BE CONSIDERED ----------------------------------- (a) Bugs! There are a (large??) number of bugs, some of which are able to crash RT-11. Identifying them (probably the biggest part of the problem) as well as fixing them will be a large part of the effort. (b) Enhancements are also very important. Just a few are: - A Path Handler - Enhancements to the MSCP device driver - Enhancements to the SL: (Single Line Editor) - Y2K for older versions followed by Y9K - Enhancements to the BINCOM program - Enhancements to the VBGEXE program - Allow use of SET commands with ANY file - Increase the precision of the TIME command to 1 tick followed by 1 msec - Being able to BOOT an LD: file While I am aware of a VERY small number of RT-11 users, the more that are still interested, the more ideas that can be generated. Please reply, either by private e-mail (first fix my munged e-mail address since the original e-mail address is no longer active) or else send a post and I will reply privately if so requested. I am also sending this post to classiccmp.org, so if you are a member of that list, you can reply either to that list or directly to me in a private manner if you so choose. Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.

19 years, 10 months

Let's develop an open-source media archive standard

by melamy＠earthlink.net

Hi Sellam, I sent off another email with a comment with regards to what I was proposing. There is a misunderstanding with regards to what I was proposing. I was not looking at having two copies of the data. Only one is required and that is what the formatting information references when it needs sector data. I think it would be better at this point for us all to try and understand all the facits of what is being done. My proposal for the data blocks are not a file specification per se. I would gather that a data block would consist of a descriptor that would indicate how many blocks comprise the data, a data type such as "file", internal data (boot sector), block ID for use with the formatting info. The formatting info would tell whether it is sequential, track/sector oriented, etc. There is no need to create a bunch of different types. Even your description created two distinct formats for data. I was being more generic in that a engineering design for a image file could be created that was not difficult and could satisfy both EASY emulator access for non-physical media access and image file description for another tool to actually create the media required. best regards, Steve Thatcher -----Original Message----- From: Vintage Computer Festival <vcf(a)siconic.com> Sent: Aug 11, 2004 9:07 PM To: "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 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. This can be done anyway. Parsing the tags should not be too difficult. And unless someone can come up with an elegant way of doing it, what you're proposing will require two sets of data in the imagefile: one in the structured format and one in an unstructured format. I suppose tags could be added to specify this is the case so that "lazy" programs don't have to go through all the trouble of parsing the structured data. > 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. You're describing an imagefile that contains a filesystem image, rather than, say, a disk image. This can be accomodated in the spec, but it's a different type of image than what we've been discussing. Remember, I envision the spec being able to handle: 1) A filesystem image (as you describe) 2) An image in "logical" format (i.e. blocks structured in tracks and sectors for a floppy, or cards for a punch card deck) 3) An image in "raw" format (a bit stream, or the actual punched holes >from a punch card deck) And there's actually a: 2.5) Magnetic media at a level below the "logical" format (decoded tracks and sectors) but above a bit-stream, which would be the raw sectors on a disk or tape including address headers, data headers, prologue/epilogue bytes, sync bytes, etc. > 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 Right. If you choose to store an image in the raw disk format. > 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. It's up to emulator writers to read the spec and adapt to it. We'll make the spec as flexible as possible, but first and foremost, the spec is intended to archive images of data media, and not to serve as a universal emulator image format (though it should be able to be used as such). > Sellam, let me know if you would like to discuss this via telephone so I > can convery the idea that I am proposing. I think I understand what you're saying. Let me know if I still don't get it. -- 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 ]

19 years, 10 months

HP diag library on disc

by jwest＠classiccmp.org

In the next week, I should be cutting a few bootable HP diagnostic library discs for both 7900 and 7905/6 media. If someone is in dire need to replace their properly licensed diagnostic set & media, contact me off-list. Jay --- [This E-mail scanned for viruses by Declude Virus]

19 years, 10 months

RT-11 / PDP-11 Software Users

by jhfinexgs2＠compsys.to

19 years, 10 months

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

>From: "Steve Thatcher" <melamy(a)earthlink.net> > >what is wrong with making things easier? ---snip--- Hi I'm not saying to make it impossible to do, just that it shouldn't be considered as a primary purpose. Using an extendable language like I've suggested, one can add such features. Part of the problem is that when someone creates the archive, they may not even know the file structure of the disk. I would expect the specification to be broad enough to allow such. Still, the primary thing is to be able to recreate the original material. To me this means that any input to some emulator may mean that it requires some post processing. How would one know what some some format a particular emulator wanted? How would a person always know how to read the directory structure and be able to extract files? If one wanted to work in all cases, I'd expect that the person writing the emulator would provide the needed post processing to extract such information. Otherwise, they'd only be able to read archives of disk that were specifically created for their system. Those archives that the person didn't know the file structure would be useless unless. Such things are secondary functions. They shouldn't be restricted >from being used, it is just that the primary function should be to capture the entire information in as close to the original format as possible. Creating post processors could easily be done as a separate outside function for special purposes. Dwight

19 years, 10 months

Let's develop an open-source media archive standard

by dwight.elvey＠amd.com

Hi Nether of these formats is totally a match for what we need. These are all just data image formats for bits. None of these describe the format of the bits. We can use the parts of these specifications we like but what ever we use will still be embedded as part of a larger file format. As Sellam says, that format needs to be extendable to handle anything that comes along. Both Intel HEX and Motorola S formats are such a small part of the picture. One thing that could be done but I'm sure many will think I'm crazy. If the files contained OpenBoot source code to describe the data, one can then create almost anything one wants. This would be something like how postscript files are done now. These file would have code that would transform the data into whatever format the user needed. One could extract the bit stream to feed as raw information to a drive or simply extract the sector data. Using something like OpenBoot code has the advantage that the source is human readable, just as postscript is human readable ( although tedious ). There could be some guide lines on standard ways to describe common formats. These would also help other describe more obscure formats. We need to remember that what normally comes out of a floppy controller chip is not the actual data on the disk. The information on the disk is a more complex. It contains things like special marks for indexing, headers and even errors. These need to be represented as well. We need to be looking at capturing the raw data from the disk. And at methods of post processing this to a form similar to what comes from the floppy controller. Dwight >From: "David V. Corbin" <dvcorbin(a)optonline.net> > >You might want to consider Motorola rather than Intel. >The only reason I suggest this is the motorola format alread has a (semi) >extensible record type description [the second char of each line]. > >S2 and S3 are already defined for 16MB and 4GB memory spaces... > >A (non-standard) record type "could" be used for media format, etc... > >Just my 16.3875 milli-EUR comment... > >>>> -----Original Message----- >>>> From: cctalk-bounces(a)classiccmp.org >>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Cini, Richard >>>> Sent: Wednesday, August 11, 2004 10:02 AM >>>> To: 'General Discussion: On-Topic and Off-Topic Posts' >>>> Subject: RE: Let's develop an open-source media archive standard >>>> >>>> I haven't read the entire thread on this but I did read >>>> Steve Thatcher's idea and it describes about where I was >>>> coming out on this myself. >>>> >>>> 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? >>>> >>>> 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 agree that a multi-layer approach offers the best >>>> combination of platform neutrality and portability. I don't >>>> really know if we need two or three layers as Steve >>>> described to describe the file in a standard fashion. Using >>>> an Intel Hex-like format would increase the "de-archiving" >>>> time, but in my view it's a fair trade-off. De-archiving >>>> software could translate the platform-neutral file into >>>> another format better suited for use in emulators. >>>> >>>> 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. >>>> >>>> Just my $0.02. >>>> >>>> Rich >>>> > >

19 years, 10 months

Tandy 10 Business Computer System

by tyger69＠chartermi.net

While reading through an old (1979) book, I came across a reference to a Tandy 10 system (complete with picture), as an example of "turnkey systems". Judging from the date of publication, I presume this is some precursor to the TRS-80, but I have not been able to dig up any more info on it. Has anyone else ever heard of such a computer before, and could you share your info, please? --T Jam the computer...trash every lethal machine in the land! -- Timothy Leary

19 years, 10 months

← Newer
1
...
36
37
38
39
40
41
42
...
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