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.