12 Feb
2010
12 Feb
'10
9:16 p.m.
On Fri, Feb 12, 2010 at 3:19 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
I'm all in favor of buffered devices - especially since CBM machines
quickly grow to 1-2 disk devices and a printer, at least, if you are
using real hardware (vs just imaging old floppies).
Is there really a significant advantage, cost or availability, between
75160/1/2s and 3448s? I've seen both used in 1970s and 1980s IEEE-488
devices and have no personal preferences either way.
How about an
AVR-based box (open, no BGAs, etc) perhaps with an SD
socket or CF socket, with an HPIB interface that will work with a)
That would seem to be a good idea.
I would suggest that the HPIB interface be buffered (using either the
75160/1/2 series of chips, which would use 2 devices, or 4 off 3448 or
similar.). ?As I mentiond a few weeks back it is a lot easier to replace
a buffer chip than a microcontorller iff something goes wrong). There should be no broblem with 'banging' the
handshake on
microcontroller port lines. HP haev been known to do this. IIRC you need
a very small maount of external logic (let me check) to ensure one signal
changes fast enough. It's only a couple of TTL chips, though (and common
ones, like 74x00), not really worth putting in a PLD.
I do recall seeing something like that in discussions on the CBM
Hackers' list - a gate or two to flip a signal faster than a 1MHz
processor can do in software.
HPIB would take 16 port lines of the microcontroller +
2 or 3 to control
the buffer driection. And then you need however many port lines it takes
to talk to the flash memroy device.
If it's quick enough, you _could_ use an 8-bit shift register for
input and/or output, reducing the MCU pincount substantially, but that
would probably only be important if you were trying to keep the MCU
below the size of the 40/44-pin varieties.
As regards code size, IIEC, the HP9133H (SS/80
protocol) has 16K of 6809
conde in it. That should give you some idea as to the complexity.
That does. Even a $4 AVR has 16K of code space these days.
> Once you have a platform that is electrically and
timing-compatible
> with HPs and PETs, it shouldn't matter if you choose to implement
> Amiga/CS80 or CBM "DOS" at the firmware level...
The Commodore and HP command sets are very different.
The major
difference is that Commodore drives are file-oriented devices (you open a
file by name, you can get a directory, etc), while HP devices are block
oriented.
Yes. In terms of complexity, the CBM command set encompasses the
functionality of the HP command set. If you coded for the PET, I
don't think it would be hard to have it also do Amiga/CS80, but I'd
have to examine the HP technique since I've never worked with it.
Yes, I know the Commodore drives let you read disks at
hte block level, but most
of the time you didn't do that. H
It depends on what you are doing. I've written many disk utilities
that "understand" the block-level format to do things like undelete
files, etc. 95%+ of what CBM users do though is, as you point out, at
the file level. You have to implement memory read and write commands
(M-R, M-W) to do things like change unit numbers, so I would consider
a strict files-only implementation to be incomplete.
Armed with disk buffer requirements (CBM drives allow the machine to
open multiple simultaneous sector buffers and read/write them - a
feature which *does* get use) and I/O line requirements, it should be
easy to narrow down the field to a handful of MCU candidates...
http://www.atmel.com/dyn/products/param_table.asp?family_id=604&OrderBy…
No BGAs in sight, but there are TQFPs and VQFNs in there.
-ethan