Memory-mapping logic - a thought

[commodorejohn]

Interesting. That does look kinda feasible.

[commodorejohn]

Well, it's been far too long since I actually sat down with this project; I'm afraid my RC2014 setup is still a pile of PCBs and components in a box at this stage. But I've been pondering lately about a simpler, alternative method for getting a functional system with nearly 64KB of RAM while avoiding the need to add a switch panel and toggle in a monitor by hand

I can't remember which thread it was in, but I recall someone mentioning recently about setting up a sort of hand-built DMA boot-loader affair which simply loads the appropriate data into the top of RAM during reset, and I rather like that idea as it means I can just set up any non-I/O access from the CPU to be to RAM, while the ROM never even needs to be mapped into CPU address space at all. What I'm more specifically curious about at this stage is how it would work to set up the initial DMA.

Basically, my thought was that I could rig up something that holds the CPU in a bus-disabled state until the initial transfer has finished, then lets it run free. Since the 65C02 already has two lines for such purposes, it seems like it'd make the most sense to hold RDY and BE low during the transfer - but I'm not sure if doing things quick-and-dirty by holding BE low at the same time as RDY (instead of waiting for it to finish what it's doing first) would be likely to cause quirky behavior when it picks up the reset process from there.

Of course, the alternative would be to simply hold the entire CPU in reset during the transfer, but I'd kinda like to have the DMA logic itself be reset along with the rest of the system, and having it both drive and be driven by the RESET line on the RC2014 bus would be...interesting.

Any thoughts on this? I'm still in the vague-concept stages on this idea at the moment, but I'm just trying to wrap my head around good practice and potential pitfalls with the bus-arbitration features of the 65C02.

[Chromatix]

For something like this, I would run a subsidiary /CPU_RST line from the DMA unit to the CPU. This would also pull BE low when active.

An alternative strategy would be to intercept the Vector Pull at the Reset Vector address ($FFFC), and hold RDY and BE low until the transfer is complete.

[GaBuZoMeu]

commodorejohn wrote:

I can't remember which thread it was in, but I recall someone mentioning recently about setting up a sort of hand-built DMA boot-loader affair which simply loads the appropriate data into the top of RAM during reset, and I rather like that idea as it means I can just set up any non-I/O access from the CPU to be to RAM, while the ROM never even needs to be mapped into CPU address space at all. What I'm more specifically curious about at this stage is how it would work to set up the initial DMA.

Perhaps you have read this. I think drogon did explain more of his way elsewhere but I'm too lazy to seek for

[commodorejohn]

Ah, yes, that's the post I remember. I'll have to poke through his other posts to see if there's more details.

Running a separate reset line to the CPU is definitely an option; I'm not super keen on having to hack the RC2014 65C02 board too much, but I'd have to run a line for BE anyway, so it's probably no bigger a deal.

[commodorejohn]

Well, it's been an age and a half and I'm neck-deep in another project at the moment, which naturally means my brain wants to start thinking about this one instead... :/ I'm a little curious about wired-OR logic in a TTL setting; the Wikipedia article on wired-logic connections discusses it strictly in terms of pull-up/pull-down resistors and diodes, but I thought I recalled reading that, with TTL logic, you can literally just wire multiple outputs to one input and get an effectively free OR gate? Or am I off-base there? Also, does it count towards propagation delay to any meaningful degree?

Because it struck me today that, if I did go with the all-RAM/IO-at-$0200 approach and a separate bootstrap circuit, I could bypass bluesky6's logic for /IORQ and /MREQ entirely and conjure up the necessary signals with just a couple inverters and wired-OR connections:

/IORQ = A15 | A14 | A13 | A12 | A11 | A10 | !A9 | A8
/RAMA = A15 | !/IORQ
/RAMB = !A15 (or possibly !A15 & /BOOTSTRAP - I'm gonna hazard a guess that a non-tristated inverter driven off a tristated output cannot reliably be assumed to be floating just because the input's floating?)

Seems like that's about as simple and fast as I could get, except for all the gotchas I'm no doubt overlooking. Thoughts?

[cjs]

Well, I'm surprised nobody's answered this yet, so I'll chime in, though I wouldn't consider myself an expert on this stuff.

commodorejohn wrote:

...the Wikipedia article on wired-logic connections discusses it strictly in terms of pull-up/pull-down resistors and diodes, but I thought I recalled reading that, with TTL logic, you can literally just wire multiple outputs to one input and get an effectively free OR gate?

You can do that with open-collector outputs, which for a low output pull the line low to ground and for a high "output" simply go high-impedence (or "high-Z"), neither delivering current to nor drawing current from the line. Typically a pull-up resistor on the line will be used to bring it actually high when none of the outputs connected to it are pulling it low.

This is as contrasted to the more typical push-pull or "totem-pole" output which actively drives the line high for a positive output. You can't wire-or these because if you have one or more outputs pushing the line high and one trying to bring it low they'll have a little battle (possibly to the death) to see who can source or sink the most current.

The issue with the open-collector wired-or systems is that they usually are slower because of the resistor between the power supply and the line. (IIRC this forms an RC network with the inherent capacitance of the circuit to determine how long it takes to pull the line up from low to high, but someone with better analogue fu than me may want to jump in and correct this if necessary.) You can of course make them go faster by lowering the resistance, which will give a "stronger" pull-up, but then you consume more current when pulling it low. Not only does this eat more power, but devices trying to pull the line low may exhibit annoying behaviour (catching on fire or whatever) if you make them draw too much current because the pull-up is very strong.

Quote:

Also, does it count towards propagation delay to any meaningful degree?

Very much so, but for signal changes in only one direction. The wired-OR "gate" will add no additional delay when pulling the line low, of course, but the time it takes for the line to go high again when released by all the devices depends on the strength of your pull-up, which I reckon is never going to be as fast as a device actively driving the line high.

[commodorejohn]

Well, it's been a fairly obscenely long time, but I'm back to devoting spare braintime to this project. I've started considering just going with a PLD solution, as BDD suggested earlier; I kinda like the notion of building things out of individual gates, but I also like the idea of things going fast and builds staying simple

But this has led to the added complication of trying to figure out proprietary programmable-logic design languages After hammering through what documentation I could find on WinCUPL (the official manual is frustratingly vague on some important aspects of how to actually work the damn thing, but this tutorial fills in the blanks pretty nicely,) I've come up with the following source file, which (if I'm understanding everything correctly) should yield a memory-mapper circuit that gives 31.75KB of RAM from $0000-01FF and $0300-7FFF, I/O in $0200-02FF, and an upper memory area in $8000-FFFF switchable between ROM and another 32KB of RAM, with the ability to write to the RAM underneath the ROM...

...but I'd greatly appreciate it if somebody who knows their way around this stuff could check my work. I believe I've written the appropriate test vectors, and the simulator reports all-clear, but as noted this is my first time even dabbling with this stuff, and I'm still learning my way around the tools/language

(Also, curious: I would infer that, with a device type specified, the compiler should tell me if I overstep its capabilities, but I'm not sure how to determine how much "room" there is left in the logic device. Is there an easy way to tell how much slack I've got in, say, a 22V10? Kinda curious what other functionality I could fit in there, if I'm gonna have it in there anyway.)

Code: Select all

Name     Mapper ;
PartNo   00 ;
Date     5/25/2022 ;
Revision 01 ;
Designer John ;
Company  aaaa ;
Assembly None ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN [ 2..9 ] = [ A8..15 ] ; /* Upper address lines */ 
PIN 10 = RAMEN ; /* Upper RAM enable */ 
PIN 11 = RD ; /* Read signal */ 

/* *************** OUTPUT PINS *********************/
PIN 14 = RAMA ; /* Lower RAM select */ 
PIN 15 = RAMB ; /* Upper RAM select */ 
PIN 16 = ROM ; /* ROM select */ 
PIN 17 = IORQ ; /* I/O select */ 
PIN 18 = MREQ ; /* Memory select; included for completeness */ 

LMEM = A10 # A11 # A12 # A13 # A14 # A15 ;

IORQ   = LMEM # !A9 # A8 ;
MREQ   = !IORQ ;
ROM    = !A15 # RAMEN # RD ;
RAMA   = A15 # MREQ ;
RAMB   = !( A15 & ( RAMEN # RD ) ) ;

Code: Select all

Name     Mapper ;
PartNo   00 ;
Date     5/25/2022 ;
Revision 01 ;
Designer John ;
Company  aaaa ;
Assembly None ;
Location  ;
Device   g22v10 ;

ORDER: RAMEN, RD, A15, A14, A13, A12, A11, A10, A9, A8, RAMA, RAMB, ROM, IORQ, MREQ ;
VECTORS: 0 0 1 X X X X X X X H H L H L
         0 1 1 X X X X X X X H L H H L
         1 X 1 X X X X X X X H L H H L
         X X 0 1 X X X X X X L H H H L
         X X 0 0 1 X X X X X L H H H L
         X X 0 0 0 1 X X X X L H H H L
         X X 0 0 0 0 1 X X X L H H H L
         X X 0 0 0 0 0 1 X X L H H H L
         X X 0 0 0 0 0 0 1 1 L H H H L
         X X 0 0 0 0 0 0 1 0 H H H L H
         X X 0 0 0 0 0 0 0 X L H H H L

[Martin A]

commodorejohn wrote:

(Also, curious: I would infer that, with a device type specified, the compiler should tell me if I overstep its capabilities, but I'm not sure how to determine how much "room" there is left in the logic device. Is there an easy way to tell how much slack I've got in, say, a 22V10? Kinda curious what other functionality I could fit in there, if I'm gonna have it in there anyway.)

The .doc file created by winCUPL is the place to look.

In the symbol table section it should tell you how many terms it's using per pin, and how many are available.

[commodorejohn]

Many thanks

[BigDumbDinosaur]

Also look in the .FIT file, specifically at the end, where you will see something such as “design FITS” if in fact it does.

[floobydust]

BigDumbDinosaur wrote:

Also look in the .FIT file, specifically at the end, where you will see something such as “design FITS” if in fact it does.

Granted, I still consider myself a newbie with WinCUPL, as I've only done two PLDs with it, an ATF22V10 and an ATF16V8, both fairly simple. However, I don't recall ever seeing a ".FIT" file generated from compiling and/or simulating the two PLDs I've done. Perhaps the .FIT file is only generated for more complex devices which require WinCUPL to assign pins and/or resources? I'm guessing here... no doubt.

[commodorejohn]

I was gonna ask that myself - I got a .doc out of it (which didn't show any variables with terms > max. terms, so I assume that's good,) but no .fit file.