From: David Wood (jbevren_at_starbase.globalpc.net)
Date: 2007-12-18 01:03:11
On Mon, 17 Dec 2007, Jim Brain wrote:
> David Wood wrote:
> > Sounds interesting no doubt. If youre using more than 64k RAM, would you
> > consider using a 65816 for linear access to the memory? I'm not trying to
> > turn the project into a super-computer with 16M ram. Rather, I'm attempting
> > to simplify buffering/ram access programming.
> >
> Wow, *WAY* ahead of me. I just pulled the parts onto a board, and made
> sure they would all physically fit on there. No design as yet :-) Sorry
> to burst the bubble.
Sorry, I was jumping ahead of you on your own design. ;) I'm good with
ideas but often wind up out of patience when attempting to get a system
working cause I design beyond my capacity to implement :-X
> > Re-reading your reply, it would seem that the 6522 could easily be used to
> > control bank addressing with a 16k window if all of its lines are dedicated
> > to the bank address. This eliminates lines for the IEC bus though. Quite
> > the challenge.
> >
> Yeah, I pulled the '22 into the design simply for compatibility with SW
> expecting to see a '22 there. There are far better parts for banking.
> > Got a preview for the board's schematic someplace? :)
> >
> As noted, sorry, you're way ahead of me. If you'd like to fire up EAGLE
> and start, I'm happy to work with you on it.
I should acquire the free edition of EAGLE. I haven't used it for ages.
More often than not, my ideas come up when the only handy thing is a sheet
of paper and pencil. :)
>
> Thinking out loud:
(Thinking out loud in reply) :)
>
> * Check out the 134 with on-board IO and such. It's not much more
> expensive that an 02.
It's not. Ive read parts of the 134 datasheet, and find it can be handy for
a few things. In order to get I/O -and- system bus though, you'll need to
use a high-pin-count package. Not exactly home-soldering heaven. :(
> * I like your idea of a 816 design, but I don't know if such a
> design would hurt compatibility. I assume it would not any more
> than using IDE, but it's a deviation.
Correct. Ive heard of loaders that use illegal opcodes in the NMOS 6502.
However, the same breakage an '816 would cause would also be caused by a
65C02.
> * I was going to suggest the C265S as the be all solution, but not
> at that price. I don't pay that much for an MPU, no matter how
> good it is.
Meh. I need to look more into WDC's microcontrollers. I've glanced, but
I'm not impressed as yet. Theyre -very- microcontroller-like. Tiny ram,
big ROM. If youre going to be buffering things, you'll need (relatively)
large external rams, so why not just use a discrete system? I welcome
commentary and more light on WDC's controllers if someone else is more
familiar..
> * Someone needs to consider the amount of RAM in a design like this
> At some point, you need more more DOS buffers (16 or so is plenty,
> I think), and some scratchpad area for IDE writes. That's a bout
> 5kB. What else would be needed?
RAM won't really be an issue. We could easily get away with as little as
32k, but a larger SRAM might actually be less expensive. If we use less
than 64k of total memory (ROM, RAM), I'd not go the 65816 route of course.
The only real advantage at that point would be the block move opcodes for
copying chunks of data about.
> * ROM needed. Should a drive contain a static large ROM/FLASH for
> the DOS, or should it contain a small minimal one and load a bunch
> of RAM with the real DOS and then protect the RAM? I tend to like
> the latter, but dunno.
For development, I recommend loading the OS into RAM via a small
kickstarter. Think of the early Amiga days, when AmigaOS was still being
developed after the A1k was released. Their solution was the kickstart
floppy, which was the system 'ROM' copied to ram during system startup.
This made for fast and easy firmware updates by just changing the disk used
to boot the drive.
This leaves another consideration of course. How does one get the firmware
to the drive, initially, and how does one recover from inadvertently
bricking the project with a bad firmware image? These are way ahead of the
design, but should be considered somewhat during the design phase when
considering boot RAM/ROM. Flash is always an option. It works well for the
Retro Replay. I lean toward the use of flash for the bootloader that
contains enough intelligence to write a new firmware image to the disk, a-la
the CMD HD's DOS.
All that said, lets follow the KISS principle to keep it as inexpensive as
we can. This is a hobby project after all. ;) With you being the
experienced engineer and me being the hobbyist with ideas, I would humbly
ask for your advice when it comes to choosing IC's and suppliers for
small-volume production.
-David
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.