VIC-20 Multicart

[carlsson]

Extended Basic should autostart when attached to $A000. Read more

Spell it Big is a Basic program, so you need to POKE 44,160:RUN. It also assumes an unexpanded machine. It doesn't do much more than define a 8x16 font and lets you type in text, but is a good example of how you can put a Basic program in ROM while the other pointers still point to RAM, if there ever was a question about if it is possible. Read more

[Schema]

As a matter of fact, you are absolutely right! We could save one chip there.

Great - looking forward to an updated schematic From there hopefully others will give some constructive feedback.

From Leo's archive I've determined we'll need >210 8K cells if we want to include all cartridges (see my spreadsheet for details).


That brings up the next big question - what should we do about NTSC vs. PAL? Seems like the majority of games are either both or NTSC only, so we could do an NTSC version right away, and then a PAL version when more ROMs are found/dumped or games are fixed.

Alternately we could do a single version with all games fixed for both - but that sounds like a huge, huge effort.

[KilrPilr]

I have since found a few more pal only games from zimmers and I am hopin gsome pal people will come forward with dumps or at least questions on how to dump. I guess though if they arent interested then this cart will reflect it. Its too bad really as I hoped to have this be a multicart for euros and north americans. Anyways dont count that archive as done as I have found alot of missing files and added them to the lot. There will be probably be more than first thought.

[eslapion]

That brings up the next big question - what should we do about NTSC vs. PAL? Seems like the majority of games are either both or NTSC only, so we could do an NTSC version right away, and then a PAL version when more ROMs are found/dumped or games are fixed.

Alternately we could do a single version with all games fixed for both - but that sounds like a huge, huge effort.

For my part, since I already have plenty of work with the hardware, I'll leave you guys the pleasure of working out the details concerning the software part.

Great - looking forward to an updated schematic From there hopefully others will give some constructive feedback.

At your service! Here is the revision you have asked for with one less chip and explicit data and address buses.

http://www.eskimo.com/~areed/eslapion/s ... artv12.pdf

Thanks AlanR for putting this online!

[saundby]

OK, then why don't you post the detail about the code that the 6502 is executing that causes this, or the electrical conditions if that's the case? I'd like to know about it. Based on what I know, I still think you're fighting the timing of the 6502, so I'd like to put that to rest if you can help me do that.

The problem with the 74LS373/374... for the last time... occurs at the very first microsecond the VIC is powered.

From what you'd posted before I got the impression that your problem came from the time between the release of the Vic's /RESET and the time you went to access the ROMs, not at initial power-up.

It serves NO purpose whatsoever to pullup the output of the chip because the problem is caused by what it latches on input. Also, any access to BLK5, according to the original plan sets the chip output to valid and will therefore defeat any effect the pullup resistors might have at that point in time.

Sure it does. It gives you an initial value. You disable the output of the register unless it gets switched on by software, much later in the process, after a valid value has been loaded into the register. You could also pull all the lines down just as well to get the first bank at startup. Either way works.

Or, as you've commented, you can use a chip with a CLEAR like a '174 and trip the CLEAR with a circuit to do so (like have it do a CLEAR while the Vic's RESET is active.)

I have no clue what an AIM65 is.

It's an older 6502-based system, which preceded the Vic by a few years. It's a bit more sophisticated than a Kim-1. A friend had one, and I played around with it pretty extensively before deciding to pick up a 6502 system of my own. I originally planned to get a Kim-1, since it was the "industry standard" for a baseline 6502 system (e.g. several books were available, it was covered well in Compute!, etc.), and it was cheaper than an AIM65. Then the Vic was announced, so I got one of those instead. The color video output drew me in, since it saved me building another TV Typewriter or taking the one I had and moving it between the KIM and my other systems that were already sharing it.

My time for building up my own circuits this last week was limited by my work, so I'm hoping to have time over the next week to put together a bankswitching circuit of my own, test it, and post it if it works. Then the forum can make what they want of it with respect to this project. It probably won't be a perfect fit since it'll be based on parts I have on hand (e.g. 4M EPROMs rather than 8M), but what's useful and what isn't will be up to folks here.

Once I'm at that point, I'll probably ask for some help putting together files to put on my board in a format that fits my ROMs/addressing scheme, since my time for programming and splicing together Intel Hex files is limited at present.

-Mark

[eslapion]

It serves NO purpose whatsoever to pullup the output of the chip because the problem is caused by what it latches on input. Also, any access to BLK5, according to the original plan sets the chip output to valid and will therefore defeat any effect the pullup resistors might have at that point in time.

Sure it does. It gives you an initial value. You disable the output of the register unless it gets switched on by software, much later in the process, after a valid value has been loaded into the register. You could also pull all the lines down just as well to get the first bank at startup. Either way works.

Look, this proves beyond all doubts that you don't understand how this archictecture works and I don't have the energy and time to argue with you.

Please follow Schema's advice...

...hopefully others will give some constructive feedback.

=============================================
Edit:
Okay... okay
I explain... look at U4 in the last plan... this chip, configured like that, has random values latched into it everytime you power up.

What you are saying is if we pull IA13-19 up with resistors, this could give this chip an internally latched value? NINCOMPOOP!

Or are you saying this could give an initial value to the IA13-19 bus ? If that's what you mean, then who CARES!! When U4 and U9 are both in high Z then both EPROMs !CE and !OE lines are high and the EPROMs aren't even active. The pullup of the resistors will be overridden by the wrong values stored in the LS chip anyways when it matters...

In order to change the values loaded into the register, it is the input lines of the chip we need to pull up or down AND THAT IS THE PROCESSOR'S DATA LINES!!!

If you disable the chip's output until a good value is loaded into it, you effectively prevent the menu software from ever starting up... Anyways, how can the architecture make the difference between a random default startup value and a so-called "good" value.

If you use LS174's instead of the LS373 to carry the values of the wanted cells for BLK1-3 and BLK2-5 then because these chips cannot be set to High-Z they will try to both force their ouput onto the IA13-19 bus and that will cause a short circuit. The same is true for the resettable LS273.

In other words, you have no clue what you are talking about and you placate us with miles of text that makes no sense.

PLEASE STOP!

The architecture I just posted WORKS and everyone else seems to agree with it.

[6502dude]

.....and I don't have the energy and time to argue with you.

Then don't

Things go a heck of a lot more smoothly with a fair exchange of ideas rather than arguments. Plus, not every post/reply needs to initiate an argument.

Please follow Schema's advice...

...hopefully others will give some constructive feedback.

Saundby has provided constructive feedback. There is simply a difference in approaches to the problem. Saundy's logic is clear to me, based on fundamentals on TTL design & CPU interfacing, and I believe he is on the right track.

The architecture I just posted WORKS and everyone else seems to agree with it.

Ummm........ there just may be a few lurkers which would disagree with your approach and do not wish to post, based on expectation of getting slammed with personal attacks.

This is unfortunate as I think we are missing out on the great depth of knowledge and experience that is out there.

You have a great deal of enthusiasm and energy in pursuit of your design and I sincerely hope it works fine for you.

[Alan]

I'm more or less a bystander in this thread-- I only understand about 15% of what you guys are debating. But geez, I think I'm following closely enough to see that saundby just got jumped on. No one enjoys being slammed like that, I don't care how wrong he might be. Especially when the guy was just trying to help out with some ideas.

Anyway, I hope saundby takes it all in stride and keeps on posting here.

[eslapion]

What I did here is only carry out my interpretation of Schema's design. Argue with him and blast him, not me.

Anyways, whatever I say is wrong...

The only reason why Saundby is persisting with this is because he doesn't understand how Schema's design is supposed to work. Two different latches carrying the value of the desired cell but expressing this value on the address bus only when the access actually occurs.

It doesn't matter that you pull that bus up or down. The value in the latch will override it when the VIC is started up and starts scanning BLK5 for the presence of the autostart code... you'll just get a random cell instead of your menu.

I might have flared in my previous post but I also answered point by point why Saundby's suggestion is NOT GOOD.

If you feel you have a better idea then do like me, enter your design in a layout software and show us a picture.

Since the original design idea for the schematics I posted came from Schema (... Schema's Schematics...) then HE should be the one you argue with. And if HE tells me I am on the wrong track with HIS idea then I will modify.

Therefore, I will implement your suggested modifications if HE agrees with it.

For the moment, my solution stands and works just fine... an LS273 cascaded with an LS373. It just WORKS...

And as Schema pointed out, we don't care that the initial cell selected for BLK1-3 is random so... no resetting is needed there and a single LS373 does the job.

[eslapion]

Sure it does. It gives you an initial value. You disable the output of the register unless it gets switched on by software, much later in the process, after a valid value has been loaded into the register. You could also pull all the lines down just as well to get the first bank at startup. Either way works.

Okay, here's a technical suggestion.

Maybe this is what you mean.

Let's assume we have two LS373 to carry the selected cells and we get a random cell at startup for both BLK1-3 and BLK2-5.

Lets completely disable the output of our BLK2-5 LS373 until we know for sure a valid cell number has been poked into it. We do this by using a resettable flip-flip with complimentary output set to 0 at powerup by the reset line of the VIC.

Lets say we use an LS175. We use the inverted output of that FF along with the output of the BLK2-5 AND gate and connect this to the !OE of the LS373 with an OR gate such as an LS32.

The inverted output of the FF is also connected back on its own input. And the FF becomes a toggle gate who's state is flipped by a clock pulse. There is your switch for the software process.

The status of the FF now decides wether the condition of the BLK2-5 lines will effectively push the selected cell onto the address bus. Since by default the FF is set to 0, the output of the LS373 is disabled and the cell available to BLK5 at powerup is always cell 0 or 255 depending on wether your resistors pull the bus up or down. The FF's CLK line is connected to the IO3 line and therefore as soon as you poke a new value to the BLK2-5 LS373 the latched value becomes valid and the FF toggles.

Okay, be my guest, it does the same and it takes only one LS373 to carry the value of the selected cell... It also requires an LS32 OR gate to recombine the state of the FF with the BLK2-5 selection line... It also requires a resettable FF with complimentary output to make the switch... it also requires 8 resistors to pull up or down the address bus while the output of the LS373 is disabled by the initial condition of the FF...

May I say this seems to be a much more complicated solution?

[saundby]

Sorry, Eslapion, you're still not getting what I'm suggesting.

Never mind, though. Here's something you might consider as a way of eliminating the '273 and power-on reset circuit. I'll be referencing your latest schematic (schema_multicartv12.pdf):

Put appropriate pull-ups/pull-downs on the IA13-19 and Q8 lines to select the bank you want at start up. At this time (start-up) it is expected that your outputs on both your 373s will be disabled by the next bit of the circuit I'll describe.

Build a latch out of your two spare gates on the hex inverter. This controls the output enables of both the 373s. Have it start to drive the /OEs high on power up, and pull them low with your cell select reset. You'll need to AND its output with the block selects U2A and U2C since you've got those controlling the /OEs on the octal latches, though, so you need two gates out of your '08, and there's only one not spoken for. So, to free up another gate you could replace your current U2B with a diode AND gate--two diodes, cathodes to inputs, anodes tied together (to your /CE lines), put a pulldown resistor of 4.7K or so on the output. <<See edit, below. >>

Now, eliminate your power-on reset circuit. Use the inverter from it for your U9 latch enable, as on U4, but to /IO3. Eliminate the '273 and run the data lines to the U9 inputs.

There are other ways to do the same thing, of course, I'm just outlining one approach using what you've already got on the board to simplify the overall circuit.

-Mark

Edit:
Sorry, I realized I'd forgotten to make the mental flip between acitve high and active low logic about an hour after I wrote this bit. It wouldn't work as written. Rather than shifting around AND gates, what's needed is ORs (negative logic ANDs) on the latch enable inputs of the 373's to tie the new latch in with the logic from the /BLK selects. Either diode ORs can be used, or an OR logic package introduced while keeping the rest of the circuit as-is.

In spite of the error, I think the idea is clear here. It's possible to do without the 273 and the power up reset circuit without adding a lot of other stuff to make up for the loss. With the proper choice of gates for the other logic, there won't need to be any more ICs added to make up for the 273 going away. I'd come up with better now, but it's late and I'm tired.

[Schema]

What I did here is only carry out my interpretation of Schema's design. Argue with him and blast him, not me.
...
And if HE tells me I am on the wrong track with HIS idea then I will modify.

I'd like to remind everyone that I have no formal background in electronics. I just try to pick up what I can quickly and offer high-level suggestions. So please do not take my design or opinions as being "gospel"!

I intended for my block diagram to be a starting point for discussion only, and that the community would discuss and iteratively improve on it and maybe even suggest something else. So far this process seems to be going as it should, though I wish people would count to 10 before they posted.

That said, I still stand by the original concept (which is just an extension of eslapion's idea), but there's this unanticipated problem of the random data at startup. I don't know how to solve that. The extra '273, from what I gather, solves that problem because it can be reset, although it does add extra cost.

[saundby]

What I did here is only carry out my interpretation of Schema's design. Argue with him and blast him, not me.
...
And if HE tells me I am on the wrong track with HIS idea then I will modify.

I'd like to remind everyone that I have no formal background in electronics. I just try to pick up what I can quickly and offer high-level suggestions. So please do not take my design or opinions as being "gospel"!

I intended for my block diagram to be a starting point for discussion only, and that the community would discuss and iteratively improve on it and maybe even suggest something else. So far this process seems to be going as it should, though I wish people would count to 10 before they posted.

That said, I still stand by the original concept (which is just an extension of eslapion's idea), but there's this unanticipated problem of the random data at startup. I don't know how to solve that. The extra '273, from what I gather, solves that problem because it can be reset, although it does add extra cost.

No prob, Schema. I'm not taking eslapion's finger-pointing to heart.

I believe I see what you're trying to do with the circuit. Basically, using a more complex addressing mechanism to maximize the number of usable memory banks out of the ROMs, allowing the accomodation of both 16K and 8K carts.

I think the worst of the confusion is actually behind us. That being that I had the impression that eslapion's data problem was a post-RESET problem caused by something in the Vic's initialization procedure, or by his circuit's operation when loading bank addresses under program control, when it's actually just a power-up initialization problem he's trying to solve. The earlier misimpression was where my timing-related posts were coming from.

While using the /IOx lines as latch enables is not something I'd bet on in a commercial product, eslapion claims to be getting good results from it, though I'm not sure whether this is in hardware or in simulation. A more canonical approach to this is to use the VR/W line and SO2 as I've described, and if problems arise later, that approach can still be used. At any rate, it's not a current issue.

Random data in the latches at power-up is where the discussion about pull-ups comes from. This is standard practice with tristate gates for specifically this reason. Unfortunately, it appears some find it unclear from earlier posts on where I intended those pull-ups to be used, and what their effects would be on the circuit during operation. With any luck, my most recent post shed some light there.

Finally, early on in my posts I was suggesting an alternate approach to addressing, which sacrifices some ROM space for simplicity, or a bit more planning to maximize the use of ROM by careful layout of the cart images in the memory map. It's a more conventional approach that only uses one octal latch, essentially a single 8-bit output port, as the bank select circuit. I wasn't intending this as a challenge to anyone's ideas, but as a simpler starting point from which more sophisticated designs could be derived if desired.

Tonight I found out that both my Vics need service when I pulled them out to try out a breadboarded circuit, so I couldn't get any testing done tonight. With any luck I'll have at least one of them ticking again soon. It looks like one needs power supply work, though the power supply prob may be the result of something else going wrong inside the Vic. The other has either a bad Vic chip or bad RAM. I'll find out which when I get it open.

-Mark

[eslapion]

I think the worst of the confusion is actually behind us. That being that I had the impression that eslapion's data problem was a post-RESET problem caused by something in the Vic's initialization procedure, or by his circuit's operation when loading bank addresses under program control, when it's actually just a power-up initialization problem he's trying to solve. The earlier misimpression was where my timing-related posts were coming from.

Thank you!

As for your previous post concerning the removal of the LS273 altogether, that makes sense. A picture, in this case, would be worth a million words.

I will come back later on and take a closer look at it.

[PaulQ]

All of this banter reminds me of a joke we computer programmers used to share:

Q: How many computer programmers does it take to change a lightbulb?

A: None. It's a hardware problem.