VIC-20 Multicart

[KilrPilr]

lol sorry Brent, I prolly had a little too much to drink last night when I wrote that. What I meant was had anyone heard of the home brew cartridges I had mentioned before like ET or amidar or madboogy. I hadnt heard of these at all whether home brew or commercial. To tell you the truth, I havent heard of those titles even on cassette so the game must be home brew too, but why would Ward have put them in the zip file of the cart roms he had for download? Do you still have the original"going away present" Ward had setup for people to download before he closed his website?

Anders, Thanks, Ill give that a try. Any ideas about kstar patrol or krazy antics mentioned in my last post?

[ral-clan]

Ummm....I actually am not sure about the going away present? If that was the complete ROM zip archive, then yes I do have that....but I don't think it's complete anymore, as HANDIC BRIDGE was just archived this past year.

As for MADBOOGY. That's got to be a home-brew. Doesn't it just play a couple of tunes? Who would market/purchase that!

[Schema]

eslapion, have you tried disabling the VIC's kernal startup routines to see if IO3 is still accessed?

i.e put the following in block 5 at $A000 on an EPROM and do a reset:

09 A0 09 A0 41 30 C3 C2 CD 4C 09 A0

This puts the VIC directly into an infinite loop at $A009, bypassing all the kernal and I/O routines.

This will demonstrate if the IO3 access is done by the VIC's kernal or not.

[eslapion]

eslapion, have you tried disabling the VIC's kernal startup routines to see if IO3 is still accessed?

The access does not seem to be caused by the kernal.

It seems that while the reset line is low, the 6502 is sort of in "drunken mode" where the address bus and the data bus just flies around with all sorts of random values.

At this point, I more or less ask you to decide if using all these chips is too much or we might go back to my original suggestion of having only one selection system, using a single 74LS273 that we know for sure we can set to all 0s at start.

In the latter case, I would suggest a system where we can decide, for example, to have 64 cells for 8k games and 32 cells for 16k games. I could arrange a config for that easily.

[Schema]

Is it only doing this while reset is low? Can we use that fact to ignore access to IO2 and IO3 temporarily?

For plan B, I would be content with the 96 games (64 8k games and 32 16k games), just a matter of choosing which ones to include/exclude.

[eslapion]

Is it only doing this while reset is low? Can we use that fact to ignore access to IO2 and IO3 temporarily?

The test I did involved connecting a 74LS373 to both IO3 and the RESET line through a AND gate made with schottky diodes, like the 5th one on the ultimate expander. In other words, the LS373 latches the data bus on the rising edge of the RESET and on the rising edge of the IO3 line.

Poking to 40959 gives the desired value. However, on startup, the reset line makes the LS373 latche on random values. This means the 6502's data bus contains random values at the very instant the RESET line goes from low to high.

Using the RC filter with schmitt trigger, I can accurately allow a LS273 to latch on the data bus at any moment I really want it to. By default it want to latch either to early, when the bus hasn't settled when the IO line is falling or too late when the C line is inverted.

As for plan B, I suggested 64 8k games and 32 16k games based on what I saw on the 8 D64 files Alan Reed has created and published on his own web site. This has the advantage of requiring exactly the same amount of ROM for 8k games and 16k games.

[Centallica]

Eslapion & Leif,

Man the knowledge you both have is amazing

I don't know what the heck you dudes are talking about but wow it stimulates the mind trying to

This is a huge work of progress for the Vic-20 Community and I have to commend both of you (and others for their input as well) here

I'm in for a cart (and will back it up with a deposit if needed)

Guess the real question is do we want to go the simple proven route with less games or have a challenge that will be even more rewarding when done with more games

I think if we pulled another person or two into this project with similar backgrounds it can be done the more challenging way

What do you guys and the community think
Brian (waving his little Commodore Logo flag from the sidelines )

[saundby]

Correct me if I'm wrong, but it looks like you're not referencing the phase 2 clock in your circuits. You need to use this to clock in the data from the 6502. Basically, the data won't be stable until just a short time before the falling edge of this clock after /W and address lines have stabilized. This may be why you're not getting good data.

A typical circuit would invert R/W, AND that with the phase 2 clock, invert your /IOx line, AND that with the output of the first AND gate to get a WE pulse to clock data into your device.

-Mark G.
(edit: changed rising edge to falling edge--that's what phase 2 does then.)

[Schema]

Guess the real question is do we want to go the simple proven route with less games or have a challenge that will be even more rewarding when done with more games

You know, we could do both. Maybe I'm overly optimistic about the VIC20 market, but I'd like to think we could make the simpler one now, and then follow up with a much improved one some time later and enough people would buy that one too.

That way, one does get developed and completed now. We can use what is learned in the process towards the improved one, or, if that never happens, at least the community has the first one.

But I'm certainly willing to spend more time+effort now exchanging ideas, to make the "current" one as good as it can be.

[Schema]

saundby - excellent observation! eslapion, what do you think?

Would a 74ls138 be of value in the circuit to handle all these inputs?

[saundby]

I don't think you need to add even more chips to the circuit. In fact, I think you can get rid of some. Here's what I was thinking of for bank control:



Depending on what else you have in the circuit (type/number of memory chips), and whether you plan on doing a pass-through or not you may want to buffer the data and address lines coming from the Vic (only the data lines are shown here, the A0-A13 lines may want to be buffered if you're using more than a couple of memory chips, depending on how much they load the bus.)

Here's a layout for the memory chips:




-Mark G.

[Centallica]

I don't think you need to add even more chips to the circuit. In fact, I think you can get rid of some. Here's what I was thinking of for bank control:



Depending on what else you have in the circuit (type/number of memory chips), and whether you plan on doing a pass-through or not you may want to buffer the data and address lines coming from the Vic (only the data lines are shown here, the A0-A13 lines may want to be buffered if you're using more than a couple of memory chips, depending on how much they load the bus.)

-Mark G.

Some fresh thoughts on the matter

Thanks Mark! (I still don't know what the frig is being said but sounds good)
Brian

[eslapion]

Unfortunately, Saundby and Centallica, you posted a lot of very intelligent things and... all of it has NOTHING to do with my current problem.

Right now, I have NO problem whatsoever having right values latched onto a 74LS374 or a 74LS373 by poking. The problem that I have is having a consistent default value at startup (and only at startup) of the computer.

Also, I would like to point out that no RAM expander I have ever seen or made uses the SO2 line to store data in a SRAM chip. The SO2 line is absoluteley unneeded.

The problem that I have right now is that only the LS273 has a reset line that will set all outputs to 0 on startup but only the LS373 has an OE line. Schemas designe requires to have both of these functionnalities. To me, the LS374 does exactly the same as an LS373 as it has no CLEAR pin. It is not resettable.

Also, Saundby, the last pictures you posted matches my original design exactly which I posted last summer and I know works because I simulated it in Altium. The difference is that using the SO2 and RW lines is simply absolutely NOT needed and I used a 74LS273 which is resettable at startup.

With your design you simply get a random game everytime you powerup because of the problem I mentioned earlier that is the IO2 and IO3 lines are being poked random values during powerup. Also, the design you suggest only allows for 16k cells.

PLEASE, before you post messages like that MAKE SURE YOU UNDERSTAND WHERE WE ARE SO FAR in our design.

The problem that we have right now is that both the LS373 and LS374 normally defaults to all outputs being high at powerup. However, the VIC pokes junk in there during reset low and the consequence is you never get a consistent startup cell. All you've posted here does NOT resolve this.

My solution was to replace the LS373s with LS273s which have a clear line. However, this makes the design incompable with Schema's design which requires an OE line for the selection of 2 independent cells.

The solution I proposed is to have an LS273 directly connected to the data bus, in replacement of the LS373 in Schema's original design then take the output of the LS273 and then use an LS373 in transparent mode only to switch between a copy of the LS273's output and high impedance.

This combination provides a resettable latch that also has 3 mode output and allows for Schema's original design to be feasible with a consistent cell being activated on powerup.

Now guys, I want you to understand it took a lot of energy and time to explain this all over again. I don't want to have to do it again.

I know you want to help but right now, this was a step backward.

If only I could post pictures, I could show you guys that just be poking a value to 40959, I was able to control 8 LEDs reliably using an LS273 and did it again with an LS373. So no SO2 needed, no RW needed... forget that.

Once again, my problem is that at startup (and only at startup) the LS373 that is required by Schema's design has a random value. Using an LS374, as you suggest changes nothing.

Okay? Understood?

[eslapion]

Guess the real question is do we want to go the simple proven route with less games or have a challenge that will be even more rewarding when done with more games

I think if we pulled another person or two into this project with similar backgrounds it can be done the more challenging way

What do you guys and the community think
Brian (waving his little Commodore Logo flag from the sidelines )

Unfortunately, I have to seriously disagree here.

1st communication of such complex information already proves quite difficult. Being confronted with posts that suggest solutions that have nothing to do with your problem and actually introduces massive confusion is demoralizing. Also, my lack of understanding of Schema's original desing proves I am not immune to doing exactly the same thing.

Intrducing more people would just eliminate any and all possibilities of a concensus which is necessary to achieve anything.

2nd, the more I look at it, the more I believe a more challenging desing would allow us to have so few more games that the line between an interesting challenge and a plain waste of energy and time is getting blurred.

True enough, my original design implied making 2 different carts, one for 8k carts and another for 16k carts.

These discussions have encouraged me to improve my original design so it becomes possible to have both 8k and 16k games on a single cart. But making a design that requires using 5 different LS chips would provide more benefits to electrical engineering students looking at the design as part of a course than to anyone actually buying it for the actual purpose of playing the games.

Alan has managed to sift through 73 8k games that work fine and 30 16k games. Of these, I am certain there are at least few that all of us would consider absolutely worthless.

BTW: KilrPilr: Since all of Alan games are NTSC compatible and tested, could you find games that are NTSC compatible and work fine but are not in his disks ? That would be great!

Schema's design allows for 256 cells of 8k that can be independently selected by pairs using 5 LS chips and 2 8Mbit EPROMs. I think this is far more than we can actually use.

My "plan B" design allows for 64 x 8k cells and 32 x 16k cells using 2 LS chips and one single 8Mbit EPROM. This design has the drawback that the number of 8k cells versus the number of 16k cells is fixed to 2:1.

I ask you all, is it really worth it to more than double the number of chips to increase the number of games by just about 10% ?

[Alan]

The D64s that Eslapion has mentioned are HERE.

These games are all NTSC. I never made an attempt to get every cartridge there is, so I'm sure there are plenty of other good games out there that I don't have. There are enough games here to practcally fill the smaller multi-cart you guys are proposing and I know they all work.