6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Mar 28, 2024 10:00 pm

All times are UTC




Post new topic Reply to topic  [ 558 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14 ... 38  Next
Author Message
 Post subject: Re: TTL 6502 Here I come
PostPosted: Fri Aug 26, 2016 9:56 pm 
Offline
User avatar

Joined: Sun Oct 18, 2015 11:02 pm
Posts: 428
Location: Toronto, ON
Just wanted to share quickly that, through one last bit of inspiration and creative use of FET switches, Dr Jefyll has managed to further enhance the 1-cycle BCD performance. The critical path on a BCD operation is the carry chain, which looks like this:

ADR.LO ('283) -> BCD.DETECT.LO ('151) -> BCD.ADR.HI ('283) -> BCD DETECT.HI ('151)-> BCD.SELECT. HI ('257)-> BCD.ADJ.HI ('283)

The revised arrangement feeds the carry from ADR.LO directly into BCD.ADJ.HI (which is an adder used before only for the BCD adjustment) so the new carry chain becomes:

ADR.LO -> BCD.DETECT.LO -> BCD.ADJ.HI

In order to make this bit of magic work, the threshold for triggering a BCD adjustment had to change on the fly. Normally. that threshold is >9 for ADC (i.e. if the result of an addition is A, B, C, D E or F, we add 6 to adjust to decimal) and < 0 for SBC (i.e. if the result is F, E, D, C, B or A, we subtract 6 to adjust it to decimal). The basic concept is to take the carry out of BCD.ADR.HI and conditionally set new thresholds at >8 for ADC and <F for SBC respectively.

It turns out the changes could all be implemented using FET switches in series and the total propagation delay is minuscule. It took some effort to adapt the idea to work with the BCD NMOS flag evaluation logic (and we lost some efficiency as a result), but it all worked out in the end.

I'm happy to report that the new BCD circuit delivers the 1-cycle BCD operation in just 58ns, vs 50ns for binary. Wow!

Nicely done Jeff :)

_________________
C74-6502 Website: https://c74project.com


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Sat Aug 27, 2016 4:38 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
(Is this an example of steering logic? I gather that was a technique more widely used when relays were the technology of choice. I like it!)


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Sat Aug 27, 2016 2:31 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3327
Location: Ontario, Canada
Drass wrote:
Nicely done Jeff :)
Thanks, Drass. As you know, I had several false starts with this idea before finally getting it right, with your and ttlworks's help.

BigEd wrote:
(Is this an example of steering logic? I gather that was a technique more widely used when relays were the technology of choice. I like it!)
The term "steering logic" is unfamiliar to me, but it immediately sounded apt. And a web search revealed that the technique lives on -- IOW I'm not the only one using FET switches (aka transmission gates) in this manner. Drass explained what's up in this recent post. Paraphrased, ...

    With CBT FET logic, the enable-time is roughly the same as a conventional part. But once enabled, the CBT version is effectively a wire, and lightning fast. The key is to use it in situations where the "enable" signal is available a few nanoseconds before the data is ready to pass through the switch. So, the FET switch gets set up in advance and the data flies through when it arrives.

Drass wrote:
In order to make this bit of magic work, the threshold for triggering a BCD adjustment had to change on the fly.
To be clear, this describes a reorganization of the decision about whether to apply a BCD adjustment. The same could be accomplished using conventional logic (not FET switches) but there'd be little or no benefit, speed-wise.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Wed Sep 14, 2016 11:28 pm 
Offline
User avatar

Joined: Sun Oct 18, 2015 11:02 pm
Posts: 428
Location: Toronto, ON
Boy, sometimes things are simpler than you think. There was but one significant “mole left to whack” in this nanosecond-hunt to 20MHz - namely, that 1-cycle BCD still lay just beyond the threshold at 58ns. I’m happy to say, in the words of J. K. Rowling, “mischief managed”! :)

I have to confess to not intending this directly. Rather, it just sort of happened, but the key was something BigEd mentioned months ago regarding how the NMOS 6502 would pre-charge certain bus line between cycles. That seemed to suggest a solution here. Let me explain:

When looking closely at the microcode control lines, I noted instances when they didn’t change from one cycle to the next. That was of little consequence before, when microcode came directly from ROM and values might fluctuate before stabilizing. Now, however, the Microcode Instruction Register (MIR) latches data at the clock-edge, and the control lines change state immediately, without fluctuation.

This is significant, because it means we can preset control lines in one cycle and keep them steady into the next. The downstream combinatorial logic will see no change at all between cycles, and, therefore, we have the opportunity to put circuitry to work early. It just so happens that BCD operations present just such opportunity.

BCD circuitry is triggered by ADC and SBC opcodes only, and as such, always requires the Accumulator ready at the ALU.A input before any real work can begin (this regularity is important - by contrast, binary ALU operations are less predictable and may operate on any register). Now, getting register A to the ALU takes time: we have to (1) latch the microcode into the MIR, (2) decode it to select the appropriate source register, and (3) output-enable that register to drive the ALU. All this fussing about may not seem like much, but takes 18.5ns to accomplish, and that’s very significant within a 50ns cycle!

Well, it turns out that much of this work can be done ahead of time. The preceding cycle to every BCD operation is an operand fetch from memory. The fetch makes no use of the above machinery, which instead sits idle in that cycle. We can therefore get a jump on things during the operand fetch to “pre-charge” the R.BUS going to the ALU with the “A” register.

When the BCD cycle proper starts, the MIR latches-in the new microcode, but the control lines which select the source register are kept unchaged. The work in-progress to that point is therefore preserved in the R.BUS and the ALU begins work immediately, with dramatic effect on the critical path. And all this is easily achieved by modifying the microcode for FetchOperand to have “A” as the default source register. That’s it! With that, 1-cycle BCD now clocks-in comfortably under the 50ns threshold. Amazing!

Now, this suggests it might be wise to implement an ALU.A latch to capture work-in-progress in a more general way - and indeed the NMOS 6502 has such latches at the ALU inputs (which I only now begin to fully appreciate). But, in this case, the pipeline logic does not allow for different FetchOperand microcode variations to accomodate all opcodes. Instead, selecting the appropriate source register has to be done in circuitry, and sadly, things are just not regular enough to make that practical (but, if I ever want to implement a non-microcode 6502, I now know precisely what to do!). So, instead of trying to chase further gains here, we’ll just declare victory on the BCD front, and move on. :D

Cheers,
Drass

P.S. One small caveat to the above: the RRA and ISC undocumented opcodes do not have a FetchOperand cycle immediately preceeding the BCD operation. They do not, therefore, benefit from the “default” source register as described above, and will still require 58ns to execute. The consequence is that software that uses these opcodes in decimal mode will force a slower clock-rate. This is a fairly obscure issue, however, and likely to come up only in very rare situations. I feel it makes little sense to pass up these benefits because of it.

_________________
C74-6502 Website: https://c74project.com


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Sat Sep 24, 2016 10:48 pm 
Offline
User avatar

Joined: Sun Oct 18, 2015 11:02 pm
Posts: 428
Location: Toronto, ON
Now that the clock-rate seems on target, it’s time to focus some attention on a little "PCB Feng Shui" - IOW, cleaning things up for good karma. Tolerances have become much tighter on the CPU, and it’s only prudent to corral any timing and signal integrity gremlins that might be lurking about.

Let’s take bus timing, for example - I was all over the map on this one, and I suppose early in the process, I could afford to be. Prior to the pipeline implementation, “enable” control signals came rather leisurely from ROM, and drivers, therefore, could hold their values stable on the bus long after the end of cycle - effectively providing ample hold-time for free. Meanwhile, signals to latch data into registers came sharply after the clock-edge, so latching was very reliable.

Now, however, “enable” control signals are dispatched directly from the Micro-Instruction Register just as sharply as latching signals, and they quickly disturb the very bus values we are trying to capture. In at least one case, the latching signal would lose this race predictably with fatal consequences. One obvious solution is to delay enable signals and thereby provide a more comfortable margin for latching. It’s tempting, but we have no such time to spare here - after all, the new data is needed on the bus as quickly as possible for the next operation. Any introduced delay simply hits the critical path of the following cycle. We’ve spent far too much effort hunting down nanosecond delays to start artificially introducing them now!

But other delays were also lurking on the bus unnoticed. A new cycle invariably implies a new driver on the bus, and signals to effect a change-over are delivered largely at the same time. The result is nasty “transient collisions” during the transition, as drivers push against each other until one finally abates and the other is allowed to proceed unfettered. Now, I know this kind of “bus contention” is commonly tolerated without consequence (after all the whole affair is usualy over in a flash, and if brief enough, its effects are quite benign). But, the fact remains that new data necessarily takes longer to stabilize on the bus under these difficult conditions than otherwise - I suspect materially so. Margins are thin, so I felt “waiting-out the storm”, so to speak, was not the best approach if it could be avoided.

Thankfully Dr Jefyll suggested an effective solution as follows: all drivers which share a common bus should be output-enabled for half a cycle only, such that every bus will switch from having a single driver active, to having no driver at all for a half-cycle. This is what a 6502 does externally on its data bus (which it drives only in phase 2). In this case, the approach works well for the W bus at the outputs of the ALU (since it too needs to be active only in phase 2, when the ALU has finished it’s work). But other buses, such as R and B at the inputs of the ALU, need to supply valid data early in phase 1 and hold it throughout the cycle. Initially, I simply could not see how this would work, until Jeff explained that bus capacitance would hold the data on the bus during the “dead period”. Once that penny dropped, the full effect of the mechanism was clear: drivers are always enabled on to a quiet bus, the pesky transient collisions are gone, transitions are smooth and fast, and latching is once again very reliable. Wonderful! As I said to Jeff, the learning never stops.

Now this scheme suffers from the unfortunate consequence that the CPU cannot be paused; since certain drivers are disabled at any one time, those buses would drain their charge and data would be lost - as happens on the NMOS 6502 from what I understand. To protect the buses, the CPU must either not be allowed to stop, or bus-hold ICs need to be installed (i.e., 74ACT1071 or 74ACT1073). I chose the latter option, simply because it seemed the more complete solution and it was dead-easy to implement.

All that remained then was to figure out which buses would be made active at which times - and that proved simple: drivers taking data data from registers to other logic early in the cycle are enabled during phase 1 only; meanwhile, drivers taking data to be latched into registers at the end of the cycle are enabled in phase 2 only. In the paths shown below, drivers to the R bus, B bus and ADL/ADH buses are enabled in phase 1, while drivers to the W bus are enabled in phase 2 (just to be clear, the external address bus, A.BUS below, is left active throughout the cycle).

REGISTER -> R.BUS -> ALU -> W.BUS -> REGISTER
REGISTER -> B.BUS -> ALU -> W.BUS -> REGISTER
REGISTER -> ADL/ADH -> A.BUS

Incidentally, I discovered that I was incorrectly driving the external Data Bus in phase 1 during write cycles - essentially causing collisions when data reverses direction between CPU and memory (Dr. Jefyll explains this phenomenon in a different context here). I doubt this would have caused significant trouble, but it was easy to sort out. The fix was, as with all other drivers, to simply use either PHI1 or PHI2 to gate the enable signals as appropriate. It’s a simple and elegant solution to a potentially nasty problem and I’m glad to have implemented it.

Drass

_________________
C74-6502 Website: https://c74project.com


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Sun Sep 25, 2016 8:46 pm 
Offline

Joined: Sat Dec 26, 2009 2:15 am
Posts: 39
Drass,

I would love to see your Logisim file.

One of the few examples of a microcoded CPU, and also in Logisim that I've found is this :

http://minnie.tuhs.org/Programs/UcodeCPU/index.html

I'm particularly interested in seeing your microcode hardware / strategy.

Mike


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Tue Sep 27, 2016 2:17 am 
Offline
User avatar

Joined: Sun Oct 18, 2015 11:02 pm
Posts: 428
Location: Toronto, ON
Happy to share mstram.

Attached is the Logisim file as well as a RAM image of Klaus Dormann's 6502 Test Suite. To make it go:

1) Load the Test Suite into the ram on the main page (Shown below)
2) Set the RDY and BE pins high
3) Start the clock (/Menu/Simulate/Ticks Enabled)
4) Hit the reset button

The test suite will start to run. Go into the "6502" sub-circuit to see all the blinking lights ... Keep an eye on RAM address $0200 to see the current test number being executed.
Bonus points if you help me find any bugs! :)

Attachment:
6502 V9 MPL.png
6502 V9 MPL.png [ 19.41 KiB | Viewed 1930 times ]

Regarding the "microcode hardware strategy", I'm not sure the Logisim file will tell you what you want to know. The file is not at all designed with presentation in mind, nor optimized for Logisim. It's sole purpose is as a working model to test the hardware - and is certainly more difficult to follow than Warren's RISC oriented CPU in the link you shared. My intention is to eventually clean this up and document it. Hope it's useful to you as is ...

For now, perhaps the following will help:

1) The microcode is vertical - that is, encoded such that it passes through decoders to generate the actual control signals.
2) There are four 8 bit microcode ROMs, two for each card in the physical CPU, forming a 32 bit micro-instruction. All the control signals required in each card are generated by decoding the ROM values local to that card. This is not particularly relevant for Logisim but helps explain why microcode is arranged in the way that it is.
3) A 4 bit "Q" state counter keeps track of the internal machine cycle. Q & Opcode together index into the ROM to fetch a micro-instruction.
4) The design is pipelined so that the fetched micro-instruction is always for the "next" cycle - there is an auxiliary micro-instruction register at each ROM to latch "special" micro-instructions
5) The sequencer is very simple, allowing only for NEXT and END directives, as well as a couple of EXIT conditions. The one subtlety is the INCDPH.C directive which handles incrementing the high-byte during indirect address calculation.
6) There are four versions of the microcode loaded into the ROMs: 6502, 6502 + undocumented opcodes, 65C02, 65C02 + select 65816 extensions. They are selected through the CMOS and +OPS switches in the internal control panel. Plain old 6502 is the default (CMOS=0, +OPS=0).
7) Decoder values for the microcode are described in the attached pdf (which may not be 100% up to date):
Attachment:
C74-6502 Decoder Values.pdf [201.02 KiB]
Downloaded 133 times

Feel free to hit me up with any questions.

Have fun!

Drass


Attachments:
Attachments.zip [52.63 KiB]
Downloaded 108 times

_________________
C74-6502 Website: https://c74project.com
Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Fri Oct 07, 2016 11:43 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1387
Some time ago, we had tinkered with the BCD correction circuitry.

The current implementation uses a modified version of the BCD correction circuitry
from my homepage for Bit 3..0, and Jeff's circuitry for Bit 7..4.

Tried to modify Jeff's circuitry to work for Bit 7..0,
but from the PCB layout I'm starting to think we don't have enough free space left
on the PCB for implementing something like this.
Also, it appears that it won't increase the speed of the CPU.

Since it might be interesting (or maybe even useful) for other people's projects,
I think it would be good to post it here before it disappears into /dev/null.

Without any warranty that it might really work, and absolutely untested on whatsoever:

Attachment:
jeffbcd8.png
jeffbcd8.png [ 214.16 KiB | Viewed 1867 times ]

Attachment:
jeffbcd8.zip [47.44 KiB]
Downloaded 76 times


The basic idea is to have 74283 adders in the ALU with the carry input tied to low
for calculating A+B, A-B.

Then to add a carry to a 4 Bit nibble as late as possible: in the BCD correction adders.


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Fri Oct 07, 2016 3:31 pm 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1387
Since the schematic above of the BCD correction circuitry might look a bit odd and confusing
to some of the readers, I think I should clarify what brought me into drawing them. :)

If you are using FPGAs, your best bet for implementing BCD correction would be "flipping the Bits"
with XOR gates, like the NMOS 6502 does as described on the homepage of this guy.

Don't mind the odd notation for some of the signals,
this article was written some years before there was Visual6502.

;---

If you are not using FPGAs, but maybe TTL ICs instead,
implementing a BCD correction depends on some more factors,
like which "function blocks" already are in the binary part of the ALU,
which parts you are able to buy and how they could be wired up,
how this fits into the PCB layout, etc.

Since the binary part of the ALU in OurCPU makes use of a carry skip adder topology,
we already might have 4 Bit adders with their input carry tied to low.
To describe the concept more into detail:

For 4 Bit, there are two 74283 adders with their A,B inputs tied together.
One adder has the carry input tied to low, the other adder has the input tied to high.
A 74157 2:1 multiplexer then switches between both adder outputs according to the carry
that is supposed to go _into_ those 4 Bits.
The multiplexer tends to be faster than the adder when it comes to the propagation delay
from carry input to carry output. (Note, that you would need another multiplexer
controlled by the carry input that switches between the carry outputs of both adders
for generating the final 4 Bit carry output.)

;---

So it was tempting to tap into the outputs of the adders with the carry tied to low
for feeding the BCD correction circuitry to avoid the propagation delay of those 2:1 multiplexers.

The logic which decides whether a BCD correction is neccessary or not becomes a bit more complicated, of course.

If you have an 8 Bit ALU consisting of 4 Bit "chunks" with a complete and intact carry chain,
for SBC, you just test the binary adder output carry of a nibble, and do a correction if the output carry is 0.
For ADC, you just test if the adder result is >$9, or if the output carry is 1.

If you _don't_ have a complete and intact carry chain, but just two 4 Bit binary adders with the carry input
tied to low, "floating in nowhere", then detecting if a BCD correction is neccessary becomes more complicated.

For ADC, you have to test if the adder carry output is 1,
if the carry that goes into the nibble is 0 and the adder output is >$9,
or if the carry that goes into the nibble is 1 and the adder output is >$8...
because the adder won't "see" the input carry, of course.

For SBC, it's a bit more complicated, because you have to test the input carry...
and depending on it, you might have to test if the adder output is $F.

As a last step during the "BCD correction", you have to add that input carry to the nibble of course.

;---

BTW: The circuitry in the schematic makes use of 74CBT multiplexers for deciding if a correction is neccessary.

TI 74AC151 propagation delay: select to Y output 4.7ns to 16.5ns, data input to Y output 3.5ns to 12.3ns.

TI 74CBT3251 propagation delay: select to output 2ns to 5.5ns, data input to output 0.24ns maximum.

So the idea is to stack a "pyramid" of 74CBT multiplexers, and to make the time critical signal ripple through the multiplexers
from data input to data output. :)


It was Jeff's idea to use such a circuitry for the BCD correction of Bit 7..4.
What eventually brought me into drawing the schematic above was that Jeff seemed to have doubts
that his circuitry could be "expanded" to handle all the 8 Bits instead of only Bit 7..4.

I hope, this description was helpful to the readers. :)


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Mon Oct 17, 2016 10:11 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1387
Drass seems to be away for the moment, so I'm adding a bit "historical" info.

Back in 2002, there had been a TTL CPU running 6502 machine code:
http://6502.org/users/dieter/m02/m02.htm

This probably explains, why OurCPU appears to be a "sandwich" built from two PCBs. ;)

The old CPU from 2002 lacked BCD mode, and it wasn't cycle compatible or timing compatible to the 6502
...you recognize the pioneer by the arrows in his back... but it already had a 24 Bit address bus.

And the question is: can we recycle some part of this old project for having a 24 Bit address bus in OurCPU, too.

;---

This brings us back to Kludge24.

Conceptually, Kludge24 is sort of a "function block" to be attached to a "standart" 6502 core.
Kludge24 has some microcode ROMs on board, and the microcode of the 6502 core would have to be changed of course.
Also, Kludge24 would need to disable the constant generator in the 6502 core which places $00 on A15..8
for zero page memory access... for being able to place the DH register on A15..8 instead.

The end result is something like "a poor man's 65816" without the 16 Bit.

Point is, that if you want to have, for instance, colored graphics with a resolution better than 320*200,
64kB of memory won't do at some point.
Resorting to odd bank switching tricks between CPU and memory might give you quite a headache later.
And trying to build a complete 65816 with all the bells and whistles won't be exactly a beginner's project.

Kludge24 just is a "step stone" between 6502 and 65816.
The basic idea is to give a 6502 a 24 Bit address bus, and most of the 65816 instruction set (except MVP and MVN)
so the CPU can make use of a (nearly linear) 16MB address range...
and when taking a little bit care, chances are good that Kludge24 machine code might run on a 65816 later
without that this requires too much changes to the code.

Bit 7..0 of the 16 Bit direct register always are 0, so it's possible to use any of the 256 pages
in the lowest 64kB of memory the "zero page", since the 'zero page' tends to be a very crowded place
in Commodore computers.

Kludge24 uses the same interrupt vectors like a 6502 (or a 65816 in emulation mode).
When a 6502 responds to an interrupt, it pushes PCH, PCL, P on stack. RTI pops P, PCL, PCH from stack.
When Kludge24 responds to an interrupt, it pushes PBR, PCH, PCL, P on stack. RTI pops P, PCL, PCH, PBR from stack.

The C64 Kernal would work with Kludge24, but there might be an incompatibility with monitor programs which use RTI
for starting a user program.


Since we have plans to be able to switch between different microcode sets by software, and I think we can live with that.
Changing the CPU design for having something like the 65816 E flag turned out to be too much fuss...

6502 (red) plus Kludge24 (blue) register map:
Attachment:
k24_regs.png
k24_regs.png [ 69.6 KiB | Viewed 1895 times ]


(Initial\preliminary) Block diagram of OurCPU with Kludge24 attached:
Attachment:
k24_mill.png
k24_mill.png [ 25.5 KiB | Viewed 1895 times ]

TBR is a temporary register for address calculation.


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Wed Oct 19, 2016 6:52 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1387
In my previous post, I had written "A (nearly linear) 16MB address range", because there are some limitations:
The 16MB break down into 256 banks 64kB each.

Incrementing PC will stay within a bank.
Branch instructions will stay within a bank.

Most addressing modes will stay within a bank,
except when calculating the effective address for a data read/write when it comes to: absl absl,x [ind],y

;---

Now a list of how I think Kludge24 should place something on the address lines A23..16:

A23..16 = $00 //page 0
  • vector fetch: RES, NMI, IRQ, BRK
  • stack push/pull
  • data read/write: addr.mode: z z,x z,y d,s (d,s),y
  • pointer read: addr.mode: (ind) (ind,x) (ind),y (d,s),y [ind],y
  • pointer read: JMP(abs)

A23..16 = PBR //program bank register
  • program memory read
  • pointer read: JMP(abs,x) JSR(abs,x)

A23..16 = DBR //data bank register
  • data read/write: addr.mode: abs abs,x abs,y (ind) (ind,x) (ind),y

A23..16 = TBR //temporary value for 24 Bit addressing modes
  • data read/write: addr.mode: absl absl,x [ind],y


Any comments or suggestions about this list from somebody with 65816 experience ?
Problem is, that I never have used a 65816 in native mode.
My info was from the manual: Eyes & Lichty: Programming the 65816.

;---

BTW: the idea is that empty microcode locations in the microcode ROM on the Kludge24 PCB
(all Bits '1') won't modify registers while placing $00 on A23..16,
to ensure compatibility with the NMOS 6502 and 65C02 which are supposed to only use memory bank 0.


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Wed Oct 19, 2016 1:31 pm 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1387
Kludge24 is supposed to be either in NMOS6502 or 65C02 mode after a RESET.
Also, a RESET clears PBR (program bank register) to $00 by hardware...
...I'm not sure, if we should clear DBR to $00 at RESET, too.

Switching between different sets of microcode could be done with a two Bytes instruction, I'd suggest using $42. //WDM
Some Bits of the second Byte are used for selecting the microcode. //immediate addressing mode, that is.

In NMOS 6502 and 65C02 mode, A23..16 is supposed to be $00.
The address decoder in the CPU for the 6510 I\O port is supposed to check for $000000 and $000001.
In a "C64 environment", the memory address decoder outside the CPU would have to decode the 64kB address range
$00xxxx (bank 0) like in a C64, and all the other 255 64kB pages of the 16MB memory as RAM or such.

;---

But in a C64 environment, this now brings us to another odd idea:

It might be possible to have programs which (from the 64kB address range) won't like each other,
like a game, an assembler and a text editor or such,
to place them into different 64kB bankss of the 16MB address range, and to jump between those programs
during run time by just pressing a button.

Let's say, we take one of the unused Bits as a "configuration Bit" to change the CPU behaviour
in NMOS 6502 or 65C02 mode like this:

The address decoder inside the CPU doesn't check A23..16 and places the 6510 I\O port at the start of every bank
in memory: $xx0000 and $xx0001.

The "configuration Bit" also has to be routed to the memory address decoder outside the CPU,
which then would place the C64 ROMs, CIAs, SID etc. into every 64kB bank in memory.

The CPU would emit PBR on A23..16 for program memory read and NMI,IRQ,BRK plus JMP(abs) vector fetch,
and DBR for the rest (including stack and zeropage access).

Then to have some switches (debounced with 7400 NANDs or such).
Pressing a switch triggers a NMI.
Since the CPU emits a /VP signal, we could trick the memory address decoder into placing
a different NMI vector and a "special" NMI service routine into every 64kB bank of memory.

The NMI service routine then saves return address, DBR and PBR somewhere in bank 0...
together with a copy of the CPU internal 6510 port output data (defining the C64 memory map),
the CIA I\O port that sets A15,A14 of the VIC2 memory access, the complete set of VIC2 registers etc.

Next, the NMI routine checks which button is pressed, then reads some values according
to _which_ button is pressed for writing a different set of values from bank 0 into
6510 I\O port, the VIC2 related CIA port, the VIC2 registers etc...
and then resumes a different user program in a different 64kB bank from there.

We would need to make the VIC2 accessing different 64kB banks too, of course...

;...

Won't probably work with 100% of the C64 software out there.

I know It can be done, because in 1988 my C64 had 320kB of DRAM and 5 such buttons.
Unfortunately, the hardware and the software are long gone, and there are no schematics. :)


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Mon Oct 24, 2016 6:45 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1387
After digging through the basement at the weekend, all I found was the casing:
Attachment:
box1.JPG
box1.JPG [ 27.86 KiB | Viewed 1796 times ]

35 years of hobby computing... and only one of my projects had a casing. :lol:
Five buttons, every button had a LED to indicate which 64kB page was active.

I remember that I tried to push the envelope back then:
Pressing a button twice made a program in a 64kB page running in the background,
what was indicated by a blinking LED.
Pressing the same button twice stopped the program running in the background again.
Buttons and LEDs were tied to a 6522, which also generated a NMI required for the
"multitasking" between different 64kB pages.

Making sure that programs running in the background won't modify the VIC2 registers
or use the disk drive was in the responsibility of the "end user", of course.

But the contraption crashed when sprites were enabled, I think there was a timing problem...
I just was unable to complete the project because at some point the C64 power supply
suddenly died with giving out over_voltage, schematics were a mess of hand drawn papers,
hardware was a lump of PCBs, components and wires... so it all went scrapped.

But enough of those old stories: Looking forward to see, what Drass could make out of this stuff.

There: "virtual consoles" and "multitasking" on a C64. ;)


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Mon Oct 24, 2016 1:16 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3327
Location: Ontario, Canada
ttlworks wrote:
35 years of hobby computing... and only one of my projects had a casing. :lol:

LOL!! -- too funny, Dieter! I'm sure this remark will resonate with many forum members. You're not the only one whose creations go "au naturel"... :roll: Nice to hear about your project.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
 Post subject: Re: TTL 6502 Here I come
PostPosted: Mon Oct 24, 2016 1:28 pm 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1387
Thanks, Jeff. :)

See, for many years I had wondered why electronics gizmos need a casing at all,
because this only slows you down when you have to repair or to modify something.

Back in 2009, another hobbyist eventually had explained it to me:
If your creations have casings, piling them up in your workshop is less fuss...


Nevertheless, I still wonder what a casing for a TTL based "C64 compatible" computer may look like.
I still vote for a "tiled stove". ;)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 558 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14 ... 38  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: