16 bit addressing on a 28c64?

[czuhars]

Hi all,
I'm building an Apple /// clone as my "first 8-bit microcomputer" project computer. And yes, I know... "An Apple /// for your first project? Do you also enjoy punching yourself in the face?" But I'm taking it very slowly.

Regardless, I'd like to use a 28c64 EEPROM for my ROM. Since the original /// used a ROM that had pins for A0-A11, I'd assumed I could use the 28c64 that went from A0-A12.

In my beginning stages, I'm building my own programmer which will let me toggle in the addresses by hand. (I'll advance to a proper programmer later). I do everything manually at first so I can understand what's really going on before I move on to automated tools.

My question is, how does one code for that last 4 address bits with only 13 address pins? I'm sure I'm missing something simple, but just curious. I know the 28c series allows for programming multiple bytes at a time, so is that how those top 4 bits are handled?

Thanks! I know I'll have more questions later on.

Edit: As usual when I post a question, the answer then comes to mind... Since the ROM's address space is all of $Fxxx, the last 4 bits are implied. So everything below that (0000 0000 0000 to FFFF FFFF FFFF) is assumed to be under $Fxxx. So the extra 4 bits are just redundant and unnecessary. Correct?

Chris Z

[GaBuZoMeu]

czuhars wrote:

Regardless, I'd like to use a 28c64 EEPROM for my ROM. Since the original /// used a ROM that had pins for A0-A11, I'd assumed I could use the 28c64 that went from A0-A12.

My question is, how does one code for that last 4 address bits with only 13 address pins? I'm sure I'm missing something simple, but just curious. I know the 28c series allows for programming multiple bytes at a time, so is that how those top 4 bits are handled?

Thanks! I know I'll have more questions later on.

Edit: As usual when I post a question, the answer then comes to mind... Since the ROM's address space is all of $Fxxx, the last 4 bits are implied. So everything below that (0000 0000 0000 to FFFF FFFF FFFF) is assumed to be under $Fxxx. So the extra 4 bits are just redundant and unnecessary. Correct?

Chris Z

Hi Chris,

I do perhaps don't understand your question: the 28C64 is an 8KB EEPROM so it has 13 address lines (A0..A12) to distinguish 8192 different memory locations. If you wish to use the 28C64 as a program storage (for booting/monitor/etc) you need to connect its A0..A12 to A0..A12 of the CPU. The higher order adress lines A13... are used to generate a chip select signal. For example a 3 bit NAND gate would yield 0 when A13=A14=A15=1. As chip select is active low connecting the NANDs output to chip select of the EEPROM would work. Then - whenever the CPU is requesting a memeory from $E000..$FFFF the EEPROM is responding. (There are also an output enable and a write enable, that both need to be controlled correctly.)

OK?

[whartung]

czuhars wrote:

Hi all,
I'm building an Apple /// clone as my "first 8-bit microcomputer" project computer.

I'd like to hear what techniques you plan on using to ensure unreliability in order to maintain that classic Apple /// experience.

[jim30109]

If you mean what do you do with A12 on the EPROM itself since you only need A0 through A11, you can just tie A12 to ground (preferably through a resistor). That way, no matter what is on the processor address lines, the EPROM will only be in the circuit when the chip is selected (as described earlier) and will only use A0 through A11.

If you really want to get tricky, you could put two different images in the EPROM and toggle between them with a switch (or even with a pin on a VIA or PIA) on A12. Some code I've been working on will do something along those lines so I have a decent debugging monitor (with breakpoints, single step, assembler, and disassembler) when working with machine code, but then can flip the switch and reboot into another part of the EPROM that has a minimalist monitor (dump, load, etc.) but also has BASIC.

Thanks,
Jim W4JBM

[jds]

whartung wrote:

czuhars wrote:

Hi all,
I'm building an Apple /// clone as my "first 8-bit microcomputer" project computer.

I'd like to hear what techniques you plan on using to ensure unreliability in order to maintain that classic Apple /// experience.

It's unfortunate that the Apple /// started life in such a bad way as it really was a good machine. A few bad decisions for an otherwise good design. The way it handles memory is probably the best design out of any 6502 system. Every other 6502 system I have seen just has a variation on a window into extra RAM but the /// made accessing up to 512k a lot easier than this. The RAM is organised 16-bits wide so some operations are faster too. The Apple //e was a step backwards in some ways.

I'm not sure how you can replicate the dual speed cursor keys.

By the way the source code to SOS and Business Basic is easy enough to find.

[cbmeeks]

jds wrote:

It's unfortunate that the Apple /// started life in such a bad way as it really was a good machine. A few bad decisions for an otherwise good design. The way it handles memory is probably the best design out of any 6502 system. Every other 6502 system I have seen just has a variation on a window into extra RAM but the /// made accessing up to 512k a lot easier than this. The RAM is organised 16-bits wide so some operations are faster too. The Apple //e was a step backwards in some ways.

The Apple /// is on my top 5 list of computers I desperately want. I just can't afford one when they (rarely) come up on eBay.

Being an owner of a Coleco ADAM, Mattel Aquarius, TI CC-40 and a TRS-80 MC-10, I'm a fan of "failed" computers.

Because in my mind, any computer you can program is never a failure.

[czuhars]

The Apple /// is such an odd-duck in the 8-bit computing world, in that it included everything and the kitchen sink, but also had an amazing amount of innovative capability for the time. I was tempted to start with a simpler SBC, then graduate to an Apple II-like system. But the /// just deserves some attention. Everything is laid out in the System Reference Manual, but for a newbie like me, it's like having to first learn a new language to understand what the text is saying. It doesn't help that there are some (relatively few) inconsistencies in the documents - like pin diagram differences in the patent drawings compared to the schematics.

With regard to the address decoding, there are many devices to touch. So the memory map is pretty full and detailed. I've pretty much followed the path outlined in the schematics, by using multiple 74LS138s - at least to access the devices I'm implementing initially. I'm primarily starting with the MPU, (initially custom) ROM, SRAM and ACIA (for serial communication to the board). As my board evolves, I'll add in additional features like the VIAs, keyboard encoder and such.

But I'm also looking at programming the 28c64. A common issue I've read from others' posts involves offsetting the entry point. So I'll have to work through these trial-and-error.

Chris Z

[BigEd]

czuhars wrote:

I'm building an Apple /// clone...

jds wrote:

The way it handles memory is probably the best design out of any 6502 system.

Agreed that the Apple III memory arrangements are very interesting - here's an explanation for those unfamiliar. In fact, we had a thread about it over here, which has gone cold but could be warmed up.

[GARTHWILSON]

I've never known anything about the Apple III. It does sound interesting.

czuhars, you will undoubtedly benefit a lot from going through the 6502 primer. Since you mention 74LS above, let me recommend abandoning 74LS in favor of at least 74HC or other CMOS logic family (but not 4000). This is addressed in the "74xx Logic Families and Timing Margins" chapter. (My apologies in advance—this particular page doesn't have any pictures to make it more attractive. The primer is organized logically though, and should be gone through, more or less in order, by anyone wanting to build such a computer.)

[dwight]

You won't easily be able to manually program the chip. The
timing requirements are quite strict.
The extra 4 bits are usually dealt with by an encoder of some type.
I'm not sure how it was done on the III. It could have been done with
select pins on the ROM or it might have been an external decoder.
I'd need to see a schematic.
How many chip enables did the original ROM have? Does it see all the
16 bit addresses? If not something on the III decodes the enables
Also, do you plan to use the software lock on the 28C64? if so, you need
to connect A12 to one of the even address lines, rather than just tying
it to ground.
You should also either disable writes, with the W* pin or use the software
lock to prevent accidental over write.
The sequential programming has to be done quickly, between bytes for
each block of bytes. We are talking micro seconds. Even individual byte
writes have some timing requirements, for maximum pulse widths.
The write pulse and enable pulse also have timing restrictions on single
byte writes.
The part was really intended to be programmed by a uP, on the buss.
I'm not sure what you mean by offsetting the entry point?
I program a 28C64 clip on my 6530 to 6530 adapter for the ROM replacement.
I do this right on the KIM-1 board. I wrap all the unused address lines
to lower addresses ( odd and even ) to keep the ability to do the software
locking. You do need a way to access the bus though. I have an external
EPROM with the programming algorythm and ROM image.
Dwight