firstname.lastname@example.org wrote: > > If I find it again and you like it I can dig out an old tex graphics I > > produced to show how I used the '610 in my CS/A65....... > > Please do. Now I found it I don't really think it is that well. It is in a gzipped postscript file on http://www.tu-chemnitz.de/~fachat/8bit/osa/v1.3/csa1.ps.gz on Page 21. Description is in german, sorry. > > You should probably now define the terms "virtual memory" and "real > > memory", with the CPU (virtual) memory address range going from 0-64k and > > real from $000000 to $ffffff. > > IMO for hardware virtual memory is memory which actualy is harddiskspace > because the machine has not sufficient RAM. The Mainframe boys here > confirmed this statement. But they said that for software it is virtual > memory as well. Confusing IMO. Indeed. You should probably avoid the term "virtual" and speak of "CPU" and "real" address. > > >> MM Map Mode input. When (H), MO0/MO3 reflect MA0/MA3, > > ^ uhm, I think I once fell for this bug too. AFAIR it's > > reflected at MO8-11, not MO0-3. Then MO0-7 would be low. > > You are absolutely right. I even had one CPU board etched with the wrong design, because I missed the point when I redrew the schematics. Took me a long time to figure out what was wrong. You know, never take anything for granted.... > > =========================================================================== > > >> for this problem is to disable Clock2 towards the original system.... > This triggered the next thought: I once tried to run a 6502 on a clock as > low as possible. It run on 500 KHz. I'm not sure if it still run at 250 KHz > but it failed to run on a lower frequncy anyway. The reason to build > dynamic RAMs is that it saves space but for those few registers in a 6502 > or other IC..... AFAIK the Z80 even can be clocked by hand if you want to. > The Rockwell R6502 specs say that the Maximum clock cycle time (of Phi0) is 10us, means it should run at a minimum of 100kHz. > So if someone can tell me more of the background of this "dynamic" > behaviour, I would be pleased. Hm, my guess still is that they have dynamic RAM registers, but this is only an assumption. Who knows more? > BTW, which ones are static and which ones not? R6502 see above R6520 : no maximum Phi2 limit, only Phi2 high time between .47 and 5us R6522 : as 6502, maximum 10us Phi2 time R6532 : as 6522 R6545 : no maximum Phi2 limit, also no lower limit on CCLK (character clock) R6551 : maximum 40us cycle time (Phi2) R65C02: "R65C02 and R65C102 minimum operating frequency is limited by Phi2 low pulse width [5us]. All processors can be stopped with Phi2 held high" R65C21: no limits, as R6520 R65C22: no limits (no maximum cycle time) R65C51: no limits Don't have other docs. But as Rockwell probably uses MOS masks for the NMOS devices, they might have the same limits. > ========================================================================== > > > the r/w line was driven high to the original system (read). > > This is not perfect, however. In fact you would have to make the > > address lines show a "safe" address to the original system...... > > That was what I had first in mind before I got that "great" idea. Address > $0000 is the most safest address for the C64/128 but this would mean using > extra ICs (541). (I don't like using "pull down" resistors, 3K9 or lower, > as they stress the bus to much) The next safe address is $FFFF; then you > only need some 33K pull-up-resistors. This seems reasonable. Open inputs normally read as high anyway (due to internal pullups) > > ========================================================================== > > I remembered an email where Frank mentioned that the reason a 6522 cannot > be connected to a 6510 straight away was that the 6522 expected a valid > address at the rise of CLK2. The difference between CLK0 and CLK2 are only The problem is not the 6510, but the fact that in the C64 the VIC disables the address lines of the 6510 with CPUs AEC input during the first half cycle. Then, when Phi2 goes high AEC enables the address lines as well and this is too late for the 6522. There are schematics to delay the rising flank of Phi2, like yours, or with using the pixel clock at the expansion port or... Don't know about the VIC20 however. > =========================================================================== > > > NO!!! The latch is used! ....... meaning that the MMU is suddenly > > deselected again. > > You're right about that. But that is what I call reprogramming it on the > fly. In my unfinnished design I have the possebilty to set MM again meaning > MO8/11 reflect MA0/3 whatever the state of CS is. Hae? changing the mapping in the middle of the write will cause a 'half-write' (or what you like to call it) to the newly mapped address? I don't think I get the point. I latch the MMU output during the first half of Phi2, when the CPU address lines are long valid and the MMU output for this cycle as well. Then the address lines stay constant during full Phi2 high, as it should be. Only at the next Phi2 cycle the new mapping becomes active. > And now I tell you my (IMHO) genious trick: as long as you use bank 0, > ($000000/$00FFFF), the 612 is working. Any other bank and the 612 is out of > function. In this way I can mix both functionalities and using the 65816s > full speed. Hm. You should probably think of mapping the addresses $000000-$0fffff (1MByte) with the MMU, i.e. with slow access. Then you can have some additional RAM in this space to replace the ROMs for example, which you couldn't do otherwise (without sacrificing 8032 RAM for this purpose). ---------------------------------------------------------------------------- No comes a rather longish text by Ruud with only a few comments from myself. Just be warned... > Hallo Andre, > > Second version > > --------------------------------------------------------------------------- > > 74LS612 > > The 612 is an MMU, Memory Management Unit, that enables you to expand your > system with 8 extra addresslines. Notify the fact that I use the word > "system" and NOT processor. The processor won't be aware of those extra > addresslines. In case of the 6502/6510 the processor still only can address > 64 KB. ^ at any one time > > > What does a MMU? > > If you own a C64 or C128 then this is easy to understand. Both machines > have at least 64 KB of RAM, 4 KB of I/O and at least 20 KB of ROM. But the > 6510 and 8502 have only a 16 bits addressbus capable of only 64 KB. How do > these numbers match? A more experienced programmer knows that he can read > the contents of the RAM "under" the BASIC-ROM but has no access to the ROM > at all at that moment. It is either RAM or ROM but not both! The same > situation occurs with the I/O, CHARROM and the under laying RAM: it is > either this or that but not all (or in this case not even two out of > three). The C128 has 128 KB of RAM but if we want to read the contents of > address $3887 in Bank 1, we are not able to read the contents of the same > address in the other RAM-bank, Bank 0. > The PLAs and the 128MMU give the C64 and C128 the ability to handle more > memory then the processor is capable of, but not simutaniously. > > > How do these 8 extra addresslines fit in the system? > > The C128 has 128 KB of RAM, 4 KB of I/O and a lot of ROM. If everything had > to be connected to a regular addressbus, we at least needed two extra > addresslines. And the C128 does not have these lines. Or does it? > Yes, it does have these addreslines but we either don't have access to them > or we don't recognise them. In case of the 128MMU they are inside the the > MMU itself. In case of the PLA the outputs of the onboard port of the > 6510/8502 function as the extra addresslines. In other words, this means > that the user/software controls the state of these extra lines by means of > one or more registers and not the processor. > > The 612 outputs twelf addresslines of which four (can) reflect the state of ^twelve > four originally attached addresslines. The PLA and 128MMU only output > ChipSelect-lines. This is one of the two major differences between the 612 > and these two C= ICs: they have onboard decoders. > The 74LS612 does not have these decoders. This means it provides the > _address lines_ like the original CPU, only more of them and nothing else. > The decoders that translate the address to the chip select lines must be > added by the user. Another major difference is that the behaviour of the > 128MMU and PLA have been preprogrammed in the factory and cannot be > changed. But with the 612 the user can (re)program its behaviour any time. > > > The 612 has 16 registers of 12 bits each. The normal procedure is to > address these registers by four addresslines. Four bits of the output are > used to replace the original four addresslines, the other eight bits to > form the extra eight addresslines. Every bit can be programmed as the user > whishes meaning that the four bits reflecting the original addresslines can > have differ with them. Reconfiguring the original addresslines gives you differ from them. > the possebility to re-arange the internal configuration of the whole > memorymap. By example in a C64 you could swap the the range $6000/$7FFF and > $E000/$FFFF to test a new Kernal-ROM. > > ####### Text graphic of Andre oh, have a look at it first. Also it's TeX, not text and more suited for my own OS. But if you get the idea, it should be easy to fit it to the C64 > The extra eight lines can be used to add extra memory (RAM, ROM) or I/O in > any way you want. A very nice example is to connect a complete 1541 to your > own system by means of a small interface which replaces the original 6502. > This interface is addressable from $01000 to $01FFFF. Now you can > reconfigure your own system in such a way that the 6502 sees the range > $010000/$01BFFF of the 1541 on its own $0000/$BFFF and the area > $006000/$009FFF as area $C000/$FFFF. In this way you comfortably can test a > new Kernal for the 1541. > > > Pinouts. > > +---------------------+ > RS2 -+ 1 40 +- +5V > | | > MA3 -+ 2 39 +- MA2 > | | > RS3 -+ 3 38 +- RS1 > | | > /CS -+ 4 37 +- MA1 > | | > /STROBE -+ 5 36 +- RS0 > | | > R/W -+ 6 35 +- MA0 > | | > D0 -+ 7 34 +- D11 > | | > D1 -+ 8 33 +- D10 > | | > D2 -+ 9 32 +- D9 > | | > D3 -+ 10 31 +- D8 > | 74LS612 | > D4 -+ 11 30 +- D7 > | | > D5 -+ 12 29 +- D6 > | | > MM -+ 13 28 +- NC / C (see text) > | | > MO0 -+ 14 27 +- MO11 > | | > MO1 -+ 15 26 +- MO10 > | | > MO2 -+ 16 25 +- MO9 > | | > MO3 -+ 17 24 +- MO8 > | | > MO4 -+ 18 23 +- MO7 > | | > MO5 -+ 19 22 +- MO6 > | | > GND -+ 20 21 +- /ME > | | > +---------------------+ > > > Pin functions: > > D0 thru D11 Connection to the databus when programming the registers > RS0 thru RS3 Connection to the addressbus when programming the > registers, normally A0 thru A3 > R/W Read, active (H) and Write, active (L) > STROBE input to enter data into choosen register, active (L) > CS ChipSelect, active (L) > MA0 thru MA3 connection to the addressbus during normal operation > MO0 thru MO11 The generated addresslines > MM Map Mode input. When (H), MO0/MO3 reflect MA8/MA11, > MO0/MO7 are (L). When (L), MO0/MO11 reflect the 12 bits > of the choosen register. > ME When (H), MO0/MO11 are tristate else active. > NC Not connected. > > > 74LS610, 74LS611 and 74LS613. > > The 610 is an 612 plus an extra 12 bits latch. With the 612 MO0/MO11 always > react on the behaviour of MA0/MA3 and MM. With the 610 you can freeze the > output as long as you want. This is archieved with an extra inputline at > pin 28, C (= Clock). A (H) on this input will the 610 behave like a 612, a > (L) freezes the configuration. > The 611 and 613 are the Open Collector versions of the 610 and 612. > > > The 12 bits registers of the 74LS612. > > The intention is to use the 612 in combination with a 6502 based Commodore > and as you know these are all 8-bitters. This means we either have to > disregard 4 bits or use a trick to be able to use all 12 bits. In the first > case we are still able to address up to 1 MB of memory or I/O. If you still > want have those extra 4 bits then a simple 74LS373 will do. Of course > you'll need a decoder for this 373 but as you need one for the 612 as well, > it won't be that much difficult to combine them into one decoder. > > > Connecting the 612 to a 6502. > > Connecting a 612 to a 6502 can be split up in two parts anyway: the memory- > part and the I/O-part. > > Memory-part. > > If you only want to reconfigure your system within its own 64 KB, then you > only have to "cut" the addresslines A12 thru A15 and to place the 612 in > the created gap. Practically this probably means you replace the processor > by a small circuitboard with onboard the original processor, the 612 and > some logic to perform I/O-operations with the 612. > If you want to use the extra addresslines as well, you have to take care of > the fact that the original hardware does not know of the addresses above > $0FFFF. So for any decoder reading from/writing to $1C000, $2C000 or any > addres above $0FFFF is equal to reading from/writing to the address > $0C0000. When reading data this will cause busconflicts, when writing data > this cause data to be written to places where it is not wanted. IMHO the > solution for this problem is to disable Clock2 towards the original system. > As far as I know all decoders and/or I/O-ICs in any Commodore use this > signal to decide to become active or not. See out Phi2 discussion. I would rather use bus driver to decouple the busses. You should at least mention that, I think. > > I/O-part > > The decision to be made is where to place the decoder for the 612 itself: > behind or before the 612. If you place it before the 612 it always will be > accessible but the disadvantage is that it can get it the way when there is > a need to remap certain areas to the area the 612 occupies. If you place it > behind the 612 and you make a mistake with programming the 612, it is > possible you cannot acces the 612 at all anymore meaning you are stuck with > the momentary configuration unless you reset your system. > > > Practical use. > > Andre Fachat built a 2 MHz 65C02 based computer, <A HREF=''>the CS/A65</A>, I gave you the URL already. > using the 74LS610. Some of the above info and ideas are based on his work. > > --------------------------------------------------------------------------- > > > Groetjes, Ruud > > > -- Email address may be invalid. Use "fachat AT physik DOT tu-chemnitz DOT de" ------Fight SPAM - join CAUCE http://www.cauce.org------Thanks, spammers... Andre Fachat, Institute of physics, Technische Universität Chemnitz, FRG http://www.tu-chemnitz.de/~fachat
Archive generated by hypermail 2.1.1.