Edit: New question added further down

Data sheet makes no mention of what type cap would be best for
74LS423 Dual Retriggerable Monostable Multivibrators

https://www.ti.com/lit/ds/symlink/sn74ls423.pdf?ts=1630760835626&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FSN74LS423

I need durations of approx. 140nS and 170nS, which I realize are quite close to the typ. minimum the chip is capable of.

Planning to use metal film resistors and multi-turn trimpots. According to the graph caps would be 10-33pF.

TIA

(Unless I figure out how to derive those pulses from 14.318MHz.)

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler

Looks like you want a delay of 4 or respectively 5 phases of your master clock: that should be possible.

Also previously mentioned, but perhaps only very rarely used, Digitally Programmable Active Delay Lines and related products from Data Delay Devices:
https://www.datadelay.com/copy-of-tapped-delay-lines-1

Sorry, this isn't really answering your question!

For a delay equivalent to 4 or 5 phases of the master clock, a simple, all-digital arrangement using an 8-bit shift register may be a better solution than an analog time delay.

Can you supply more detail regarding the problem you're trying to solve? In particular, what's the intended use for the output of the analog time delay? If the output is going to be fed back into the system's digital logic then it may well require a flipflop to ensure proper synchronization. If so, this increases the chip count for the analog solution, lending extra appeal to the all-digital shift register solution.

-- Jeff

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

Don't laugh. The idea is to create a low "gap" in VIC20 1MHz clock high so there'd be two highs in ~520nS, boosting the speed to 2MHz.

If a slow, I/O address is detected when Monostable-1 fires, Mono-2 won't get triggered and "2MHz" stays high the full 520nS. If the rising edge of NON-delayed Mono2 latches Slow (about 30nS before delayed Mono-2 goes high), 2MHz stays low and whatever the 65C02 was going to do would be deferred until the next cycle, when Slow would be detected during Mono-1, etc., etc.

There's more to it than that: I'd have to duplicate VIC's orginal 1MHz O1 and O2 for VID access and the VIAs' timers. I'd have to replace the slow onboard 5K of RAM with 70nS 8K. I'd also have to put RAM "under" the Basic and Kernal ROMs so they could be copied there before going to Fast mode. The alterations to memory are actually Part 1 of this crazy plan. Attempting 2MHz would come after that.

I've tried to come up with an all digital scheme but that was beyond my design skills, so much so that I suspected the chip count would amount to more than the monostables scheme, which at this stage is five, which isn't too terrible.

I could be wrong about all this.

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler

Hm, a very intriguing idea! I'm not laughing, but this project is rather ambitious. It's good that you're treating the upgraded memory as "Part 1" -- a separate and preparatory goal.

I get the part about copying the ROM to the fast RAM that's "underneath" (ie, mapped to the same address range, but initially selected only on write cycles). But where would the code for the copying reside? I'm guessing you'll either provide a small additional ROM or you'll replace the ROM with an (E)EPROM and shoehorn the copying routine into some unused space therein.

As for the clocking business, I'm pretty sure an all-digital solution will be both doable and preferable to using monostables. But as background for those of us reading, can you attach or link to a VIC20 schematic please?

My hunch is it'll be easiest to disconnect the first stages of VIC's clock generation circuitry and hook in our own replacement instead. It'll be nice if we can use an oscillator that runs at double the present frequency, because then all the changes will happen on the rising edge of the clock. But if such an oscillator can't be procured then our clock generation circuitry can be designed to produce changes on both the rising and falling edges. That will be slightly trickier to design but it's not a show stopper.

Stepping back, though, to look at the big picture... I'm a little concerned that the project might fail even if the clocking is made to function exactly as you envision. (I know almost nothing about the VIC20, and maybe my fears are groundless.) I guess the double-speed cycles will involve only the CPU and the RAM. Remember the RAM will need a separate Write-Enable pulse for the extra cycle you're squeezing in.

Another concern is that double-speed code may fail to interact properly the VIC chip. ie; it's plausible that they wrote their VIC routines to meet certain cycle-accurate requirements. Or maybe there's simply an implicit reliance on VIC-related code executing at a certain pace. I don't know how you could answer this question in advance. But these are the sorts of things that are best considered before you invest all the effort, not after!

-- Jeff

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

-- which is in fact more ambitious than what my summary suggested.


VIC's memory map divides 64K into eight 8K "Blocks." BLK0 is shared with the 6560 Video Interface Controller. (Which gives the VIC20 its name.) BLK4 ($8000-$9FFF) is where I/O resides. BLKs 6 & 7 are where the system ROMs live. Enables for BLKs1,2,3 and 5 are available on an edge connector at the back of the case. (Also two 1K enables for external I/O circuitry.)

On start up, after some fundamental initialization steps, Kernal code checks for the presence of auto-starting code in BLK5. Usually this has been in ROM cartridges plugged into the back. I plan to have banks of RAM and EEPROM in BLK5 and the ROM copying routine could be in the EEPROM, where it could auto-start, then continue the rest of system initialization. Or I could call the copy routine manually from Basic before going to Fast mode. There'll be a bit in a Configuration register for that, as well as a mechanical switch that can force Slow mode.


The only version that fits on one sheet is the earliest rev. Later models are on multiple pages. I use Rev D, here:
http://www.zimmers.net/anonftp/pub/cbm/ ... index.html
They're actually six half-pages: I had to paste a couple together to get the Big Picture of the sections relevant to what I want to do.

There's also this
http://mainbyte.com/vic20/n_schematic.pdf redrawn by someone as three sheets. It's quite huge, and the only error I''ve noticed is the "1" is missing from 6502 Ø1 out. There might be others.


That won't be necessary. What I'm calling True 1MHz (T1M) comes from an open collector 7406 hex inverter. To create a gap in in the high phase I need only pull that output down at the proper time with another open collector -- and there just happens to be one unused 7406 inverter on the Rev D board. Lucky me.

Commodore used two NORs and two inverters to Validate VR/W, and that circuitry should perform correctly when it receives 65C02 Slow/Fast Ø1 and I substitute /2MHz for PØ1. The added memory will need an OR, however, because I want to be able to Write Protect BLKs5,6,7.

VIC chip's operations occur during Clk Low, and that will remain 480nS. Its registers would still be updated at the 1MHz rate because they're in thje Slow region BLK4. I'm more concerned that some "legacy" programs would fail because they use the NMOS illegal op codes. Disabling Fast mode won't fix that.

I plan to use 74ALSxx wherever I think propagation delays might be concerning, keeping mind that some of VIC20's functioning depends on prop. delays.

I do have an all digital solution in mind, but I haven't worked it all out yet. You guys probably won't like it. The thing about the Monostables design is I can adjust where the Monostable 2 generated gap occurs in True 1MHz High by varying the duration of Monostable 1. So, if I do stick with that design one question remains: What type of capacitor would be best for the timing?

I really appreciate the interactions here. Thanks.

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler

Sorry to have ignored the capacitor question. I'm no expert on all the different varieties, but I've posted a link and an attachment below. I think we can be confident that a mica cap is one of the types that'd be satisfactory, and here is a Digikey search, ordered by cost, for mica caps in the 10 -33 pF range which are also in stock. Most of them are a bit pricey, unfortunately.

It looks as if NP0/C0G ceramic caps also deserve consideration. I know from experience that these can be hard to work with due to their tiny size when it comes to specimens in the pF range, and for that reason you may wish to choose a higher voltage range than you require, simply to get a physically larger part!

Here is a 33 pF through-hole film cap that'd be satisfactory, but this variety is seemingly unavailable (or at least not in stock) in lower values.

I'm still ruminating re an all-digital delay, but the monostable approach should also be workable, given that the pulses you're generating don't have tight timing tolerances. So, it comes down to a question of package count. (Also, the digital approach won't require trimpots.)

There's a detail that occurred to me about the CPU doing pairs of double-time cycles. Presumably this only happens when the CPU is reading or writing RAM... which is to say there's no involvement with (presumably slow) IO devices. If you haven't already, you need to consider the case where the first cycle of the pair addresses RAM and the second addresses slow I/O. It seems to me you'll be forced to delay completion of that second cycle, either by clock stretching or by pulling RDY low.

-- Jeff
See also here: How To Select a Capacitor

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

_________________
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?

That really is an ambitious project. I'd probably use a shift register with Phi2 as input and something like dot clock as clock, and combine the outputs to the signals I need.

Instead of using too much of the vic20 itself, you could also replace just the CPU with a whole computer that just uses the vic20 as IO. I did a similar thing for the vic20's predecessor, the Commodore PET http://www.6502.org/users/andre/pet816/

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Almost overwhelming replies and information.

Thanks, Garth, for the capacitor facts I didn't know I didn't know! I do have some MLC caps but all I know about them is they're 50V and "T.C Z5U", and since you said to avoid anything with a "5"... if what I have when I get to breadboarding aren't up to snuff I'll get what you've recommeded.

What you said regarding caps' voltage rating in audio apps was eye-opening and quite relevant to my other hobby, and explains some of what I've observed in that field. (Still, I don't plan to now throw away all my 12 or 16V caps, though.)

Jeff, your tentative approval of the monostable method is encouraging, and the Capacitor Comparison Chart -- which is also a source of things I didn't know I didn't know -- is filed for future reference. Good info in the "How To Select a Capacitor" link too.

Hmmm. I had given that some thought and concluded it wouldn't be an issue, but I'll reassess those conditions. I really don't want to get into clock stretching and/or using RDY. Basically, I don't see how that would work with part of memory being shared with the vid controller.

What I hadn't considered is what happens during system interrupts, which in Commodores happen every 60th of a second for "housekeeping." Since that almost exclusively affects I/O it means the system would slow to 1MHz every 0.0167 seconds -- something CBM never mentioned about the C128 'fast' mode. Anyway, that too is something I'll have to thought experiment.

And fachat, you gotta be kidding, to say my project is ambitious, then point me to your pet816 Most impressive, but not something I'd have any delusions of being able to pull off.

And to quote myself:

At this stage even I don't like it, so the less said about it the better.

Thanks also to respondents I haven't mentioned.

In a few days, in a new thread, I'll post my plan for expanding VIC memory, which in some ways might be even crazier that 2MHz.


Richard
p.s. edit for fachat: VIC doesn't have an accessible dot clock.

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler

Before I can make any progress on an all-digital solution for increasing the VIC-20's speed, I need to know Commodore's reasoning for making the yellow waveform fall after the blue one does. (~15-20nS)


How faithfully will I need to duplicate these relationships, since VIC'S VIAs will need an unchanging 1MHz SØ2 for their Ø2 inputs? Would simply delaying "True" 1MHz -- which would cause a pseudo-SØ2's rising edge to also be delayed -- be good enough for the VIAs?

SØ2 + address bits enables VIC's address decoders, but plays no part in generating the VIAs' CS1 and /CS2: address bits do that. SØ2 doesn't play any part in validating WRite, either, although Ø1 out does.

Any theories/speculations appreciated.

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler