If anyone is interested, I just posted the following on VCM:
* Apple IIe Enhanced, 64K, two Disk II drives, one Unidisk 5.25" drive, one
Unidisk 3.5" drive, ProDOS, three disk controllers, three Super Serial
cards, one parallel interface card w/cable, and AppleColor Composite
Monitor.
* Commodore C64 in original carton, power supply, manual, composite video
cable and switchbox.
* Commodore 1541 disk drive with Zork I, II, III, Pinball Construction Set,
more.
Hi,
I noticed a post you made some time ago about recovering files from
old HP64000 5.25inch floppy disks.
I have the same problem, some old HP64000 floppies which I would
like to get the contents off.
I would be gratefull for any information on the HP64000 disk format
and any tools you found to do this.
Cheers
Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: terry(a)beam.ltd.uk Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
"Tandems are twice the fun !"
>> I'm not as familiar with the 6809 as I am with the 6502... what differences
>> in architecture make it better? Larger stack frame? More (and larger)
>> registers?
> It also supports more addressing modes than the 6502 like position
>independant (indexed off PC) and indirect addressing (in C, this would be
>dereferencing a pointer). It also has a fairly orthogonal instruction set
>which also helps in compiler writing (in my opinion). Of all the 8bit CPUs,
>this happens to be my favorite.
One of the biggest advantages of the 6809 to a compiler is the fact that it does
all kinds of stack relative addressing. The 6502 can't even push/pop all of it's
registers let alone perform relative or indirect stack addressing with them...
This ability makes it very easy to deal with C's stack based local variables.
For example, you can access memory on the stack (or through any index register)
with a 0, 5, 8 or 16 bit offset, and you can use an 8 or 16 bit accumulator to
calculate an offset. You can also perform indirect operations using stack based
pointers, all in a single instruction. Plus, all index and stack registers on the
09 are 16 bits. The 6502's 8-bit index registers are somewhat at odds with C's
notion that a pointer can point 'anywhere'. So, on the 6502, you end up using
zero page 16 bit "registers" a lot, and these involve more overhead to manipulate.
The 6809 is also my favorite 8-bitter (perhaps that's why there's 6 CoCo's in my
collecion). The very first edition of my C compiler was targeted to the 6809. At
one point I even designed my own portable 6809 computer (hardware and software),
you can see it (and even try it out with a simulator) at my "old computers" page:
http://www.parse.com/~ddunfield/museum/index.html
Look for entry called "D6809". In addition to the OS, the system has a "bunch" of
utilities, several editors, an assembler and a simple implementation of APL. there's
even an 8080 emulator which allowed me to easily bring over code from my Altair which
was my main computing platform prior to this one.
It's disappointing that the 6809 never received as much acceptance or use as it should
have. It was truly in a class by itself. Motorola documents show two circles, one
containing the words "8-bit" and one containing the words "16-bit". A third circle,
linking the other two contains the word "M6809", and this is a good description of the
part. It was an 8-bit CPU with a great deal of 16 bit capability.
Btw, I have scanned the "Motorola M6809-M6809E Microprocessor Programming Manual" and
a fair bit of other 6809 reference material, which is all available on my site.
Regards,
--
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
Vintage Computer Festival <vcf(a)siconic.com> wrote:
> Has anyone got the original Windows 3.0 install disks?
I have 13 complete sets, each set being 7 3.5" DD (720 KB) floppies in a sealed
cellophane bag. They are old and the welds that held the bags sealed weren't
very strong, so some of them are coming apart, but they are basically
"unopened".
Seeing that there is interest, I'll try to find time to read them and put the
images on my FTP site.
For those who want the real original disks, rather than just images, since I
have 13 sets, I'm willing to sell them except one. If interested, make an
offer.
MS
A while ago I put together a 486/66 system to play around with all my windows 3.1 apps I have used in the past. I was wondering what the fastest VLB video card ever made for windows 3.1x was. I remember Diamond bragging about its Viper cards back in the day being the best, but who knows.
Google has allot of information about what the best DOS gaming card was, but not that much on windows 3.1 (which is what I am interested in).
Also what's the best video intensive benchmarking app to test out cards with?
I have the following cards (and others but they are slower):
Diamond Viper VLB 1mb VRAM
Diamond Viper VLB 2mb VRAM
(while both have the P9000 chip for windows acceleration they have 2
different chips for vga)
Diamond Video 3000 (Stealth 64 Video Vram VLB) 4mb (S3 968 Chipset)
Diamond Speedstar pro VLB 1mb DRAM
Hercules graphite 1mb VRAM (IIT chipset)
Matrox Plus 2mb VLB (early matrox chip and a very long card that has space
for another 2mb vram)
These cards are from the early 90's so it should be on-topic for the list.
At 23:59 28/04/2004 +0100, you wrote:
>> case, an inadaquate keyboard (CoCo1) and artifically limiting system software (for
>> example, the CoCo ROM's required DP to be "Page Zero" - and hogged most of it).
>
>But the ROM could be switched out and the machine run with a RAM-only
>memory map. If you had any sense you booted OS-9 which did this and which
>gave you a multi-tasking OS, the best I/O system I've ever come across,
>and some very nice languages (a decent C, ISO level 0 PASCAL, and the
>best BASIC I have ever used on a micro [1]).
Yes, absolutely - and I did run OS/9 on my CoCo sometimes when it was an "in use"
machine... however I do recall that when initially getting going with the machine
"out of the box" it was frustrating to figure out why they had done some of the
things they did - I guess the real problem is that the CoCo was designed "on the
cheap" and did not have things like a real serial port, and relied on a lot of ROM
software to make other devices work.
It's funny - in a way you've made my argument for me - That you needed to run a
completely separate third-party system in order to allow the CPU to be used anywhere
near it's potential is pretty much the point I was making.
Btw, I did not buy my first CoCo to run OS/9 - I wanted to put my own os (CUBIX) on
it, and I found it required much more learning/understanding to get to the point where
I could "take over" the machine than it did with other systems (Boot puts one sector
>from disk-0 here, here's the disk controller, here are serial ports to talk to terminal
- a bit of typeing and you are up and running...). Having the ability to make use of
existing ROM code for the devices - at least initially - would have helped.
All I'm saying is that this ROM heavy/limiting design was one factor (and only one
in a larger list) that prevented the machine from widespread acceptance/third party
support. This is consistant with the CoCo's design as a "cost is everything" home
"appliance" console, not a serious business/scientific machine which is what the 6809
CPU was worthy of.
And this is not necesarily a complaint - just an observation as to some of the reasons
a decent machine with an outstanding CPU didn't do better than it did. Unfortunately
it is the only common machine using the 09 that most people knew of, and this did not
help to win 09 supporters.
I believe SWTP made a nicer 6809 machine, however I never did get my hands on one :-(
--
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
