GARTHWILSON wrote:
The only bug with the VIA is the serial input when the shift clock is external. There's a way around it (which I'm doing), and very few users even think of using it anyway, but it would be nice if that were just fixed.
That, and the annoying implementation of the IRQ. I won't even mention the equally annoying R/W timing issue. I've never liked the 6522 and see it as a throwback to the bad old days of the Commodore VIC-20 and its royally screwed-up architecture. You notice the 6522 was not used in any Commodore 8 bit machine after the VIC-20. Even the much-maligned Plus-4 doorstop didn't use that crappy piece of silicon.
Anything I might do with a homebrew design I can just as easily implement with other, more modern silicon. Now, if WDC were to develop a high speed CMOS analog to the old MOS Technology 6526 CIA found in the C64, C128, etc., I'd consider it. The 6526 is what the 6522 should have been, especially with its much saner IRQ setup, better timer arrangement, and AC-driven TOD clock. That said, the Dallas 1511 RTC has what I need in a timekeeper (plus 256 bytes of NVRAM) and has a straight-forward bus interface and IRQ arrangement.
Quote:
...as I see it, your computer so far has almost no I/O.
Garth, it's a "proof of concept" unit, and is not intended to be a "practical" design. It has enough I/O for me to drive a terminal plus exchange bytes with another machine. I will use it to develop a ROM BIOS, which will become the basis for a more ambitious design with more I/O capability (possibly including SCSI—SCSI and I are old friends dating back to when it was known as SASI).
BTW, the 2692 DUART can run up to 115.2 Kbps CBAT simultaneously on both ports, and has numerous programmable I/O pins that I'm not using (two each are used to implement CTS/RTS on the two serial ports). Also, I can add more serial ports in the future with one or more SCC2698 octarts—that's eight ACIAs in a PLCC84 package. No more logic is required to select one of the eight ACIAs than is needed to work with the 2692.
Also in the back of my mind while I was designing this thing was the desire to keep the board size at or below the 21 square inch limit of ExpressPCB's ProtoPro product. Adding more I/O would have used more board real estate, and staying under 21 square inches would have been difficult to achieve. As it is, I created an alternate design in which the bus drivers are absent, further reducing the board size. I may build both for comparison purposes. What the hell, it's only money.
Quote:
You do already have a lot of glue logic though.
That's because I decided to extend the RAM address space up to $CFFF. If I had used the simpler method of mapping SRAM in and out with A15 alone I would have been able to eliminate some logic. Also, you should note I more thoroughly qualified R/W to the SRAM to avoid any possibility of a timing glitch during write ops. Both the DUART and RTC have /CE, /OE and /WE inputs, which demand more qualification than can be gotten with a simple two-state read/write line.
The amount of glue logic isn't really a liability in this design. The next version will definitely use a PLD and do away with the discrete gates.
Quote:
I have mulled over the idea of banking inside the first 64K address space, ie, having say an 8KB window into a multi-megabyte memory, with an output port selecting which 8K in that big memory the window lets you into, but I run into problems that are worse than the 816's banking issues. It would be nice to just have 32-bit registers and buses so banking would be a non-issue.
Back in the early 1990s I wrote code to run on an SBC powered by a 65C02, with up to 8 megs of RAM (on 30 pin SIMMs), a 2698 octart and a GAL to handle the logic. The memory map was as follows:
Code:
$xx0000-$xx7FFF segmented RAM, where $xx selected one of 128 RAM segments
$008000-$008FFF I/O & memory control
$009000-$00BFFF common RAM
$00C000-$00FEFF ROM or common RAM
$00FF00-$00FFFF ROM
I was told the above map was the best that could be done with the available GALs of the time. Basically, it came down to not having enough I/Os on the GAL to map anything more ambitious.
The thing ran on an 8 MHZ clock and due to memory mapping being controlled by a single register in the GAL, a context switch was accomplished with a simple STA instruction, taking only a few clock cycles to complete.
Quote:
From your signature line:
Quote:
New technology isn't necessarily good technology. Consider Microsoft Windows...
See
http://en.windows7sins.org/ , "Windows 7 Sins: The case against Microsoft and proprietary software" What an endictment!
Unfortunately, the computer press at large continues to treat Microsoft as though they invented the computer, just as Al Gore supposedly invented the Internet. In the words of an author who wrote a scathing piece on the way the press treats Barack Obama, it's a "slobbering love affair."
fachat wrote:
Although I assume you know about my 6502 with MMU.. I just couldn't resist
64k CPU address space divided into 4k blocks, each selectable from 1MByte physical memory. Even including no-execute, write-protect, and illegal address (i.e. not mapped) bits per page.
And an operating system using the virtual memory to support memory separation between processes...
I've extensively perused your website.
You obviously have more than a little experience with UNIX-like operating systems. Now if I could only get your assembler to generate an output listing...