That explains some of the performance data you've mentioned. Fortunately, chip technology has advanced a bit from those days.


Uh, forgot about the SID. It has to run at a constant 1 MHz, so the ultimate system speed is going to be limited no matter what. As you've said before, you can get away with murder at 1 MHz.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

You'd have to make sure that a valid ISR vector exists at $xxxxFFFE no matter what, and that vector had better be pointing to an ISR, no matter what. Otherwise, the reset push button will get worn out.

It all sounds like way too much complexity to me. Of course, I'm just a curmudgeon...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think you gave a link to the TI 74HC138 data sheet before and said it was about 15ns max; but I'm looking at http://www.ti.com/lit/ds/symlink/cd74hc138.pdf (their current 74HC138 data sheet) which says that at 6V, 50pF load, -40 to +85 deg C, the max is 33ns, and http://www.ti.com/lit/ds/symlink/cd74hc154.pdf (their current 74HC154 data sheet) which says that at the same voltage and temperature range the max is 37ns. 5V will make it a tad worse, but 25 deg C will make it a tad better. There will be small variations between brands, but these are approximately what my '88 data book said. I expect they will keep any given family about the same, but as technology advances, they have introduced new families.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks for all your replies!


yes, I saw that design of yours, I wouldn’t come up with something like that on my own, so I planned some headroom.

I definitely want to include a variable and from software selectable clock.

That was my intention, 32k of program space is way enough for my skills.

I thought I have 2 or 3 lying around doing nothing, so why not using them. But considering all this, I’ll have to agree.

I absolutely agree, programming in ML on the C128 is not that much fun. I’d rather use BASIC V7.0. Well, except for the lack of speed.

You don’t mention 74HCT for a reason?

actually my supplier does have both, .300” and .600” DIP.




Most of you are advising me to use an ‘816. I’m open to that suggestion, but I have some concerns.

First of all, banking would be just a nice addition, certainly not a necessity (to me at least). I’ll be using a Gameduino for VGA out. At startup, I have to write a charset to it.

In order to familiarize myself with the ‘816, I would like to see a few different schematics of some SBC’s. Like yours and BDD’s POC. I don’t know if they are online, but if they do, I’ll find them. Are there any other’s online?

I’ve started to read the ‘816 datasheet and it looks rather impressive.

I’d really like to include a 6581 SID and a 8580 SID, they have to be in there! However, it would be silly to run the whole system with 1MHz. Can they be implemented if the system is running on a higher clock (2,4, or 8MHz.)? I’m pretty sure that PHI2 of the SID has to be (around) 1MHz. What about R/W? I will make a variable clock with a selection register and run it at 1MHz. while using the SID. But that’s not so elegant. Does R/W operate at 2 MHz. at “FAST MODE” on the C128? Does any one of you have a SID in your SBC? I know the KIWI has. It runs at 10MHz but has an E output.

Another concern are MOUSER’s ridicules shipping costs (20 euros). I’m living in the south of the Netherlands near the German border, so I could order from both countries.

I understand for higher clock speeds I need either AC logic or CPLD. My “bug vendor” has only 18 different AC chips and some of them are SMD at 1.27mm pitch. That’s probably doable for me. CPLD wise I’m a total beginner. Just knowing that it can replace TTL and is pretty fast. I’m building a simple CPLD parallel port programmer and a test board with an XC 9572XL PC44 at the moment.

If I’m going to build my SBC (MARC-2) around an ‘816 I’ll be having far more questions than when I choose a 65(C)02. I’d be heavily depending on your help and advice. And progress will in any case be slow due to my illness.

So for my first SBC I’d skip some steps and experiences.

Edit1: found BDD's POC schematics. Nice!

_________________
Marco

See attached, which is a current NXP (formerly Phillips Semiconductors) 'HC138 data sheet.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

So they're similar. Page 7 has the HC showing 38ns max at 4.5V and 33ns max at 6V, 50pF load and -40 to +85°C, and page 8 the HCT showing 50ns max for HCT at 4.5V, same load and temperature range.

http://www.ti.com/lit/ds/symlink/cd74ac138.pdf shows the 74AC138 having 10ns worst case at 5V, 50pF, -40 to +85°C, which finally makes the '138 suitable for much higher operating speeds. If there were an ABT138, that'd be the cat's meow, but I haven't found one available. I've been able to find and buy several different ABT's since you alerted us to them, but alas, many in the family are not available in ABT. One I'd sure like to find is the '521 or '688 8-bit equality detector. Address decoding would be a major application.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

ACT and HCT inputs are TTL-level compatible to allow an LS device to drive a CMOS device. If everything is CMOS (which it should be in new designs) there's no need to use ACT or HCT. Incidentally, 74ABT logic, despite the name, is CMOS. It features single nanosecond performance and high drive strength. You'd only use it if you were trying to take a 65C02 or 65C816 all the way up to 20 MHz.


We have answers...mostly.


A bit of technical pedantry: "banking" in the 65C816 sense is nothing like what you would see in a C-128. The C-128 was dependent on the actions of the 8722 MMU and the PLA (which was most of the C-128's glue logic) to select one 64KB bank or the other, maintain a common area at low RAM, and map ROM and I/O in or out as needed. The ability to configure a common area was de rigueur as without it, bi-directional cross-bank transfers were all but impossible (BASIC would not have been able to run). Also, the C-128's kernel had to write some ISR front-end code into both RAM0 and RAM1 to assure that the 8502 would have a place to land when an interrupt occurred. That code had to push the registers, read the MMU configuration at $FF00 and push it, and then write $00 to $FF00 to map in the kernel ROM. It was a complicated and somewhat fragile arrangement with which I got very familiar back when I professionally programmed that machine.

In contrast, the 65C816 can address a full 24 bits of RAM with minimal glue logic (a 74AC573 or 74ABT573 latch to drive A16-A23 from D0-D7 and an out-of-phase clock to gate the '573) and without the need for common RAM areas. Several ways are available to access the entire 16MB space without any special steps, including using a 24 bit direct page (aka zero page) pointer. When an interrupt hits, the '816 will go back to (program) bank $00 to fetch the ISR vector and start executing the ISR without the rest of the hardware having to do anything special. When the ISR RTIs, the '816 will return to the bank in which it was executing when the interrupt hit, again without the system logic having to do anything special. That is all in stark contrast to the hoop-jumping done by the C-128, and is much simpler than trying to make a 65(c)02 address more than 64KB.

That said, you aren't obligated to use the A16-A23 address component at all, and can completely ignore it like I did with my POC V1 units. As long as the glue logic is correctly implemented, the '816 will pretend it only knows about a 16 bit address bus and will behave like a 65C02 on a big dose of steroids. You can run the '816 in emulation mode (the default at power-on or reset) until you get comfortable with your system, and then start exploring native mode and 16 bit programming. Once you get some experience under your belt with this hardware you can design version two with A16-A23 decoding hardware and rig up as much RAM as you want.


You'd do that in your reset handler. That's basic I/O. What are you going to use to read a keyboard?


That's because it has more features than the 65C02. Don't let it scare you. Ninety percent of the assembly language is the same. The other ten percent is where the '816 really differentiates itself from the 'C02.


That's not going to be a trivial thing to implement. The usual method of interfacing a slow peripheral device to a fast system is to use wait-states to temporarily halt the MPU. When the MPU is wait-stated by asserting (negating) the RDY input, it stops execution of the current instruction and holds all signals that it is driving in the state they were in when the wait-state started. The wait-state gives the slow device enough time to respond to inputs and do what it is supposed to do. Upon release of RDY, the MPU will resume execution of the current instruction.

Unfortunately, none of the NMOS versions of the 6502 (including the C-128's 8502) will respond to RDY when the current operation is a write. This shortcoming was addressed in the C-128 by implementing a hardware feature referred to as clock-stretching, resulting in all accesses to the I/O block ($D000-$DFFF) occurring at an effective 1 MHz rate, no matter the MPU frequency. Clock stretching temporarily increases the effective clock period to one microsecond during actual chip access, which allowed Commodore to use the 6581 without alteration (also true for the two 6526 CIAs).

As both the 65C02 and 65C816 will halt on a write cycle when RDY is asserted, you can use wait-states to access the SID. The device's Ø2 input would have to be phase-synced with the MPU's Ø2 clock so when the MPU is wait-stated on a SID access the latter's clock is in a high state. You could do this with cascaded flip-flops to divide the MPU's Ø2 clock to 1 MHz. The flops would have to be very fast to avoid having the SID's clock get significantly out of phase with the MPU's clock. I envision that you'd have to use programmable logic to achieve all this. Attempting to do it with discrete logic will likely result in too many cascaded propagation delays.

Aside from the timing issues, getting a 6581 (NMOS) or 8580 (HMOS) operating on a bus driven by a CMOS MPU will present a problem or two. As is typical of devices of that era, the SID has weak fanout, so direct connection to a data bus full of other hardware may not work, forcing you to use an octal transceiver to "boost" the SID's output. I don't know if anyone has tried such a thing, so you might be breaking new ground here.


€20 does seem steep for shipping small parts that weigh a fraction of a kilogram. Perhaps some forum members who live in your area could offer suggestions on obtaining parts.


The fastest discrete logic available today is 74ABT. Some gates are as fast as 3ns. Unfortunately, 74ABT isn't available in all logic types, so your next bet is 74AC. You can use 74HC if you don't plan to ramp up the clock too much. A simple system with 74HC might be able to make it to 8 MHz, but that 125ns cycle time will be getting tight. You have to keep in mind that the MPU is doing stuff on both halves of the clock cycle and that read/write access occurs only during Ø2 high. That's 62.5ns at 8 MHz. I've "stress tested" my POC unit at 15 MHz (without access I/O) and know that it wouldn't be able to run that fast with 74HC logic.

PLDs are available at 10ns and faster, which is a pin-to-pin prop time (internal gate prop times are not additive in the usual sense). A reasonable system can be built around a 10ns GAL, such as a 22V10, with the GAL handling I/O decoding and wait-states. You'll run out of resources with a GAL if you get much more complicated. That's where a CPLD becomes attractive.


1.27mm (0.050 inches), also referred to as SOIC, can be hand soldered. My POC V1.1 unit has an SOIC SRAM and SOIC form of the MAX-238 transceiver. The SRAM has J-leads and the MAX-238 has "butterfly" leads. Despite the close pitch, my not-so-steady hands and less-than-sterling eyesight, I was able to solder both without any trouble. I discuss the technique on my POC website. There are also some videos on U-Toobe that illustrate various techniques.


A CPLD is just a whole lot of gates in a single die, so if you understand the use of discrete logic, you are half way to getting a CPLD to work for you. The languages used to program CPLDs (CUPL, VHDL, etc.) do most of the hard work for you.


I and others around here always advise first-time builders to exercise restraint in developing a homebrew computer. Trying to incorporate too many features and/or an idiosyncratic memory map into the design almost guarantees that the unit with be DOA on first power-up and difficult to debug. In other words, it's best to learn how to pilot a single-engine light plane before stepping into the cockpit of a 747 or A380.


Excellent. My website is due for more updating but time has not allowed me to do a long burn on it. The schematics you found, however, contain the hardware bug-fixes that corrected timing issues that popped up in the initial unit (V1.0).
-----------------------
Edit: I attached the schematics for POC V1.1, which are more up to date that the schematics you found. As I said, I need to update the website. I omitted the SCSI host adapter schematic.
-----------------------

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

You can see the effect of having that extra bit of circuitry at the HCT device's input in the speed reduction.


I've found no references anywhere to an ABT version of the '138. Most of the ABT logic is in basic gates and bus drivers/transceivers, the latter being an application where the ABT logic really pays off.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The important thing about the 816 is that it's almost pin-compatible and it boots into a 6502 mode.

I'd advise against increasing the scope of your project to accommodate all the features of the 816 - it's the kind of thing which gets in the way of finishing anything (or even starting anything)

So, by all means buy the 816, but do build an 8-bit system first! And stick to 8-bit software, until you have something running.

Cheers
Ed

Exactly. You've essentially described POC V1.0. Version 1.1 merely rolled in the hardware patches and added some circuitry needed to take advantage of the SCSI controller's DMA channel. If the SCSI host adapter is unplugged and the Dalla watchdog is plugged into the "expansion port," the unit will boot directly into the M/L monitor and will look like V1.0 (minus the bugs).


Your advice is correct, of course.

As I had said, I ran POC V1.0 in eight bit emulation mode for quite some time before switching to native mode and rewriting the BIOS into 16 bit code. I first fired up the unit in December 2009 and didn't permanently switch it to native mode until August 2010, by which time all known hardware errata had been eliminated and most, if not all, bugs in the firmware had been corrected. The switch to native mode operation was also when I recoded the BIOS to take advantage of 16 bit operations. I haven't looked back since.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

So, has any one given any thoughts to a 65816 memory map, considering the CPU vectors are at the top of the first data bank.

Lot of talk about a 6502 8 Bit map, but, what were you thinking BDD for v2.0 with 4MB of RAM? Were you planning on leaving Bank 0 alone, or solely for the supervisor, and load all of the user space above it?

Sorry for the delay but I will respond properly tomorrow...

_________________
Marco

Hrm, 65816 D and S registers are both 16-bit, and constrained to bank 0, so that should be mostly-to-completely RAM... Or something stupid-clever, such as making it ROM for interrupt-vector and code fetches, and RAM for data operations. Mirror the ROM somewhere higher up in the address space as well, and possibly use a resettable latch to control the overlay of the ROM into the RAM space...

The RESET sequence would basically be CLC, XCE, JML to ROM space, then something to hit the latch to allow executing code from RAM. No fuss, a little muss, a contiguous RAM region at the bottom of the address space, a decent-sized ROM region (I'd use sst39sf040 512kx8 ROMs), and there's plenty of open room for I/O.

That's a first approximation, of course, I haven't really thought about it too deeply, or about the consequences of not having I/O in bank zero (where it could be twiddled by dpage instructions), or about precisely how to implement the address decoding logic.

Samuel Falvo had a clever way to do something like that. Can anyone remember some search terms to find it?

Note however that direct pages and the hardware stack together do not need very much of bank 0. Even if you have many tasks running at once that have their own DP, as long as they don't need anywhere near a whole page each, those direct pages can overlap without stepping on each other. The same goes for individual tasks' stack spaces.


I asked about having I/O in a bank other than bank 0 at viewtopic.php?f=4&t=1484 and there was some discussion there.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I usually just let the I/O decoding appear in all 256 banks. It does waste a 2k or 4k block in each bank but it make access of IO from each bank much easier.