VIC-20 Multicart

[eslapion]

Technical sidenote, in Schema's "upgraded" design, the 74LS373 is only used to switch on and off the output of the bank selection devices, in this case, the LS273s.

Therefore they can be replaced with 74LS244 chips.

[saundby]

I won't bother to quote the rant post due to length.

However, I went through all the posts in this thread front to back before posting, referring back to the ones most concerned with the hardware repeatedly. What I thought I saw was a description of a system where gate delays were being used to try to get stable values on the inputs for selects. This didn't seem to be a good way of managing the circuit timing, so I brought in the phase 2 clock line since this is standard 6502 I/F practice for clocking in data for I/O such as chip selects, I/O ports, etc. It's typically not used for RAM or ROM communications, however.

I understood that you were getting random data that was causing problems with bank selects at startup, it seemed to me, from what was communicated, that timing problems could cause this. Likewise, several disclaimers were made about having a full understanding of the working of the circuits as presented, so I felt the comments would be welcome and I spent a fair bit of time putting together a drawing to make sure that my comments were communicated clearly, rather than simply throwing out an off the cuff comment about the clock and leaving it at that.

As frustrated as you are with the situation, throwing a fit isn't helpful here. Perhaps you should be sure that you've been clear in stating your position before getting bent out of shape about other people not knowing _exactly_ where you are in a project. To be honest, if that's your standard you're not going to get much help. If I waited for exact knowledge before pitching in on anything, I'd never get anything done.

Now, if you want to initialize your original value it still seems like you're adding a lot of chips to do a simple job. With a 3xx chip you've got tristate outputs, so pull the lines up with some resistors, and disable the register output at startup. Once you've loaded a valid bank select value, enable the output with a decoded input, either in conjunction with the /IOx line you're using and the address lines or whatever. At least that way if your inputs are truly random you'll only get a random bank 1/256th of the time. Put your menu in the bank that's selected with all select lines high.

Better yet, let's figure out what the heck the Vic is up to at startup that's causing your problem. I built a banked memory board many, many years ago and never had this problem myself. It used pretty much the same technique I drew up, but with buffering to support more, smaller, ROMs and some 8K NOVRAMs, all of which load the lines heavier than the newer EPROMs we're looking at here.

If I turn up the board out of whatever box it's in in the garage I'll see if there's anything unusual about it, but I certainly don't recall anything unusual. It was a board I'd originally used on an AIM65 that I'd rewired for the Vic, and it worked fine without any tricks to avoid random selects at startup.

So I hope you can see why I feel it may be some problem with your circuit not clocking in data correctly that makes be think its the circuit, not the Vic.

It's been a long time since I've ROMmed anything for the Vic, but I don't recall the Vic going past the ROM search in its startup sequence when there was something present at $A000. Perhaps someone here can give us a breakdown of what the startup sequence is that's more detailed than the programmer's guide? (Or point me to another thread where that's discussed, I haven't turned up what I'm looking for with searches.)

-Mark

(edited to add some detail to the discussion of controlling the /OE on the latch.)

[eslapion]

... if you want to initialize your original value it still seems like you're adding a lot of chips to do a simple job. With a 3xx chip you've got tristate outputs, so pull the lines up with some resistors, and disable the register output at startup.

That would entail disabling the effect of the BLK5 line for a few millisecs after the rising edge of the reset line and therefore prevent any software in the multicart from starting up. That includes the menu software... NOT good.

Once you've loaded a valid bank select value, enable the output with a decoded input, either in conjunction with the /IOx line you're using and the address lines or whatever. At least that way if your inputs are truly random you'll only get a random bank 1/256th of the time. Put your menu in the bank that's selected with all select lines high.

I'm sorry but I understand absolutely NOTHING of that. If you do what you said above then you could manually poke in the number of the cell you want for BLK5 and just by doing that, the selected software will be activated by the external reset trigger system.

Unless you're implying I forcibly pull up the data bus of the 6502 at startup which could cause a short circuit and destroy the CPU... unwise.

Better yet, let's figure out what the heck the Vic is up to at startup that's causing your problem. I built a banked memory board many, many years ago and never had this problem myself.

This figuring out is already done.

What bank selection method did you use? Was it necessary for that device to have the same bank activated by default upon powerup? Anyways, the LS273 resolves my problem. And that's IF there really is a problem in the first place because Plan B does NOT require a 3 state output anyways.

If I turn up the board out of whatever box it's in in the garage I'll see if there's anything unusual about it, but I certainly don't recall anything unusual. It was a board I'd originally used on an AIM65 that I'd rewired for the Vic, and it worked fine without any tricks to avoid random selects at startup. Then it is very likely that the bank number was selected using a resettable octal flip-flop

See... RESETTABLE flip-flop... the LS373/LS374 are NOT resettable and THAT is why it has an inconsistent value at startup. Since the data bus is directly attached to that chip then it latches on the junk the 6502 feeds it when it powers up.

And may I remind you that in the VIC, the duration of the reset pulse is more than 1 second in duration, just about 20 million times longer than what it takes for the LS373 to latch onto the first value it can grab. When connected to nothing at all the internal pullup resistors of the chip makes it latch onto a consistent 255 or all ones.

And since Schema's design also requires that the latch have a 3 state output, in order to make it work you must create a virtual resettable 3 state output latch. Since there is no octal latch in the LS catalog that is both 3 state output AND resettable, I create one using an LS273 and an LS373 or LS244.

So I hope you can see why I feel it may be some problem with your circuit not clocking in data correctly that makes be think its the circuit, not the Vic.

There is noooo clocking problemmmmm.

It's been a long time since I've ROMmed anything for the Vic, but I don't recall the Vic going past the ROM search in its startup sequence when there was something present at $A000.

No, I don't think it does that. And I never said it does that. As a matter of fact I did say to Schema that the random junk on the data bus causing random values to be latched on startup with an LS373 is BEFORE the rising edge of the reset line on powerup. The 6502 can't be doing much ROM search at that point, it can't be doing anything at all...

Anyways I just spent 4 hours entering my understanding of Schema's solution in Altium DXP.

I'll make a PDF out of it and ask Alan to post it here.

Next step is entering Plan B.

[Schema]

There is noooo clocking problemmmmm.

Sorry eslapion, first thing I thought of


I'm starting to get out of my technical depth now, so I may join Centallica on the sidelines, but I'll follow along of course and comment where I can. I think we're making good progress though!

Any suggestions from 6502dude, ruud, Leeeeeeeeeee, Thomas? Speak up!

[Centallica]

I'm starting to get out of my technical depth now, so I may join Centallica on the sidelines, but I'll follow along of course and comment where I can. I think we're making good progress though!

Leif, with you out and with Elaspion never big on the dual chip idea, I think we should resort back to his "Plan B" of the smaller game cart and put the larger cart project for afterwards like you suggested....any thoughts?

Any suggestions from 6502dude, ruud, Leeeeeeeeeee, Thomas? Speak up!

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

Would be your answer to that question Leif

So how does the rest of the group feel about the Plan "B" idea?

If all who are buyers are in agreement with this, I guess we need to do a poll of some sort on the game selection. I would vote not to include kiddie or utility roms like Face Painter etc. I would vote for the "A" games and "Rare" to find games...any thought???

Brian

[Schema]

Don't overreact, I'm not "out", just not likely to be able to contribute schematics or suggestions at this level of detail.

I think it's worth spending some more time and discussion to see if there's an affordable solution to the random data problem, or maybe a variation to the approach.

All the combined experience and background of the Denial members is quite a strong asset, we should make the most of it. So I appreciate your and eslapion's eagerness, but I think it's still too early to try to get to a consensus on the design.

Designing by forum is slow, I'm sure we'd have this solved in a few hours if we were all in the same room.

Let's not forget it's a hobby too!

[6502dude]

I think it's worth spending some more time and discussion to see if there's an affordable solution to the random data problem, or maybe a variation to the approach.

I believe there is merit it in saundby's design sugestion to resolve data bus instability problems.

6502 datasheet timing diagrams and standard CPU interface techniques support this.

As with software development, with hardware design there are often multiple ways to achieve similar results.

Let's not forget it's a hobby too!

I agree totally. We all should be having fun doing this

[Centallica]

Don't overreact, I'm not "out", just not likely to be able to contribute schematics or suggestions at this level of detail.

I think it's worth spending some more time and discussion to see if there's an affordable solution to the random data problem, or maybe a variation to the approach.

All the combined experience and background of the Denial members is quite a strong asset, we should make the most of it. So I appreciate your and eslapion's eagerness, but I think it's still too early to try to get to a consensus on the design.

Designing by forum is slow, I'm sure we'd have this solved in a few hours if we were all in the same room.

Let's not forget it's a hobby too!

I think with a comment from Eslapion like "Intrducing more people would just eliminate any and all possibilities of a concensus which is necessary to achieve anything." means that he's not willing to work with anyone else coming to the team and Saundby's attempted help is an example of this with his frustrations.

So, Eslapion, what is your stand on the cart?

A) Plan "B" and get it done

OR

B) Be willing to work with others to design the larger cart

OR

C) Work on the larger cart by yourself

D) Both A and B

I'm out of discussions on this cart from here on until the game selection comes into play and you want my order for one of these babies!

Brian

[KilrPilr]

I say dont give up on going for a full multicart. I have confidence that eslapion/schema/others can figure this out. So what if it takes a few extra parts? a couple dollars here or there isnt going to kill anyone. Also being that this is a hobby, there is no rush to get this cart to market. There is always going to be a market for this sort of thing so lets just do it right or not at all, is my opinion.

Not having most of all the available known cartridge games on a multicart seems like a failure to me. It would be like buying a lamborghini with a 4 cylinder motor or a cadillac with no power windows/locks/cruise control. Maybe im being overly dramatic but thats what I think about making a half ass multicart.

[eslapion]

To Centallica,
I want to work with others but not with people who offer solutions to problem that don't exist. And not with people who introduce confusion by suggesting configurations that are needlessly complicated.

However, if you believe you can suggest alterations to these WORKING designs that can IMPROVE them, by all means, please do so.

(Isn't that exactly what Schema did when he suggested a double independent selection architecture?)

The larger cart is ALREADY designed and the design WORKS FINE but it requires more than double the number of circuits of Plan B. It is simply a question of cost.

I will give you all the schematics to both Plan B and Schema's twin selection system as soon as I humanly can in PDF format.

Keep stomping on me like that and I will forget this project altogether and I will do... nothing at all.

I believe Leo will soon tell us exactly how many working games we can actually put in such a cart and that will help us all decide wether we want a cheaper solution or a more expensive one with double the content size.

Thank you for your cooperation and your understanding.

[saundby]

... if you want to initialize your original value it still seems like you're adding a lot of chips to do a simple job. With a 3xx chip you've got tristate outputs, so pull the lines up with some resistors, and disable the register output at startup.

That would entail disabling the effect of the BLK5 line for a few millisecs after the rising edge of the reset line and therefore prevent any software in the multicart from starting up. That includes the menu software... NOT good.

Once you've loaded a valid bank select value, enable the output with a decoded input, either in conjunction with the /IOx line you're using and the address lines or whatever. At least that way if your inputs are truly random you'll only get a random bank 1/256th of the time. Put your menu in the bank that's selected with all select lines high.

I'm sorry but I understand absolutely NOTHING of that. If you do what you said above then you could manually poke in the number of the cell you want for BLK5 and just by doing that, the selected software will be activated by the external reset trigger system.

Unless you're implying I forcibly pull up the data bus of the 6502 at startup which could cause a short circuit and destroy the CPU... unwise.

You're not pulling up the bus, you're pulling up the bank select lines to force a selection of your ROM bank. It's not on the 6502 bus, and your selected bank will be sitting there at $A000 for the 6502.

Also, pull-ups do not short circuit anything. They're resistors, not hard connections. Further, the connections I'm talking about tying high are the outputs of the octal latch. They have no connection to the 6502.

Better yet, let's figure out what the heck the Vic is up to at startup that's causing your problem. I built a banked memory board many, many years ago and never had this problem myself.

This figuring out is already done.

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.

What bank selection method did you use? Was it necessary for that device to have the same bank activated by default upon powerup? Anyways, the LS273 resolves my problem. And that's IF there really is a problem in the first place because Plan B does NOT require a 3 state output anyways.

I used an output port with either a pair of 7475s or 7474s to do the bank selection. On another board that has since been scrapped I used a 74100 as I recall. Boot was always consistent, it booted into a version of FORTH that I'd hacked on the first bank. I was experimenting with some ideas I had on software-based memory management with this board. I wanted to make it so that a programmer using a mid-level language like FORTH could access far more memory than was in the memory map, both ROM routines and large quantities of RAM. As I mentioned, I started out experimenting on an AIM65, then brought it to the Vic. I didn't get far on the Vic with it because I ended up pursuing other interests there. So I packed it away, probably with some other old 6502-based homebrew equipment rather than with my Vic stuff, which is mostly at hand.

If I turn up the board out of whatever box it's in in the garage I'll see if there's anything unusual about it, but I certainly don't recall anything unusual. It was a board I'd originally used on an AIM65 that I'd rewired for the Vic, and it worked fine without any tricks to avoid random selects at startup. Then it is very likely that the bank number was selected using a resettable octal flip-flop

See... RESETTABLE flip-flop... the LS373/LS374 are NOT resettable and THAT is why it has an inconsistent value at startup. Since the data bus is directly attached to that chip then it latches on the junk the 6502 feeds it when it powers up.

Poor choice of words on my part. I didn't mean a FF with a reset, but a FF which could have its value changed in software. My favorites have almost always been the '74s for applications like this, and that's most likely what I used.

]So I hope you can see why I feel it may be some problem with your circuit not clocking in data correctly that makes be think its the circuit, not the Vic.

There is noooo clocking problemmmmm.

Somehow I find that comment less than convincing, and not especially helpful to our conversation.


At any rate, I'm breadboarding a circuit since that'll get us further than any amount of conversation. You mention the speed of the TTL chips versus the 6502 signals, that's exactly why I'm bringing up the issue of how the data for the bank select gets clocked into the latch. With a MOS memory you can rely on just using the R/W and address lines to get data in and out of the memories with the 6502's timing. With TTL, you're going to be passing through a bunch of garbage unless you clock it in properly.

Anyway, if you get some hardware that works, rather than a simulation, let me know. If you have a schematic that I can use to recreate what you've got, I'd like to see it. I'd like to recreate your problem with hardare here in front of me if possible and see if I can offer further insight into it. If you've got more sarcasm, save it for another time.

-Mark G.

[KilrPilr]

ok i think i have these roms sorted again. Could still use some dumps from our euro friends out there. Get them in to me if you want them included in the cart!!

ok so for PAL only rom images there is:
15- 8k games
2 - 16k games

for NTSC only images there is:
78- 8k games
23- 16k games

for NTSC/PAL (games work in either standard) there is:
47- 8k
12- 16k

about 6 of these games are duplicates. IE: they are in both pal and ntsc only folders.
there is also 8 other games I couldnt get to work. could someone else please test these!? Download the file here, http://members.shaw.ca/holymoly/VicCartRoms.zip
and the games are in the folder labeled "couldnt get to work"

PLEASE PLEASE Download this zip file and test or redump or dump whatever is missing and let everyone know. Otherwise if you dont speak now, it may not get added to the cartridge.

Does this help you eslapion??

[eslapion]

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.

It can't possibly be with a piece of code because at that point in time the 6502 is still under a reset condition. Because the 6502 pushes random values on the data bus at that point in time.

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.

In other words, the VIC will see a random cell there and if it turns out to contain the A0CBM startup code will start running the code and you can forget any hope of poking a different value to the LS chips.

In order to resolve the problem you would have to temporarily disconnect the data bus of the 6502 from the LS373 and pullup the INPUT while the reset line is low. It is not unfeasible but it would certainly require just as many chips as cascading a 74LS273 with a 74LS373.

I could do it with 2 LS373s cascaded together. The one connected to the data bus would remain in High-Z during reset and pin 11 shorted to 5V to keep it in transparent mode. But in this case, not only would you need 2 chips to do the job, you would also need 8 resistors to pullup the intermediate bus between the chips during reset when the first chip is in High-Z mode because there is no garantee the internal pullups will be enough. It would also consume more power.

I already gave you all the details to this problem...

I have no clue what an AIM65 is.

Somehow I find that comment less than convincing, and not especially helpful to our conversation.

Look, I am not here to convince anyone. Please make sure you understand the exact nature of the problem, if any, before you post.

You try it. Turn on and off a few millions of times a 74LS373 with nothing connected to all the inputs and pins 1 (output control) and 11 (latch control) shorted to the ground. By default the LS373 will latch to all high because of the internal pullup resistors.

However, if you connect the inputs of the LS373 to the data bus of the VIC and the IO3 line via an inverter to pin 11 then you can control the outputs of the LS373 just by poking to 40959 and the outpus will reflect the binary value of what you poked.

However, every time you powerup the VIC, by default the LS373 will latch on the very first value it "sees" on the bus while the 6502 is still undergoing reset.

It has nothing to do with a timing problem because poking a value to the IO3 address range works reliably and consistently.

I have truly no clue what could make you believe any timing problem is involved in this. I looked at it with a logic analyser and the problem is very clear.

The LS273 is unaffected by this problem when the CLR line is connected to the reset line coming from the VIC. However, it does not offer a 3 state output and, once more, that is why I connect the output of the LS273 to an LS373 or an LS244.

Any more questions ?

[eslapion]

ok i think i have these roms sorted again. Could still use some dumps from our euro friends out there. Get them in to me if you want them included in the cart!!

ok so for PAL only rom images there is:
15- 8k games
2 - 16k games

for NTSC only images there is:
78- 8k games
23- 16k games

for NTSC/PAL (games work in either standard) there is:
47- 8k
12- 16k

about 6 of these games are duplicates. IE: they are in both pal and ntsc only folders.
there is also 8 other games I couldnt get to work. could someone else please test these!? Download the file here, http://members.shaw.ca/holymoly/VicCartRoms.zip
and the games are in the folder labeled "couldnt get to work"

PLEASE PLEASE Download this zip file and test or redump or dump whatever is missing and let everyone know. Otherwise if you dont speak now, it may not get added to the cartridge.

Does this help you eslapion??

This does help considerably. However, the numbers are a bit frightening.

A version of the multicart destined to NTSC machines could carry up to 160 games regardless of the size. (78+47+23+12=160)

However, a PAL version could only have 76 games to offer. (15+2+47+12=76)

I actually believed there would be more PAL only games than NTSC only games. That seems weird to me.

Are you sure of these numbers Leo ?

[eslapion]

Awright, here is a preliminary plan that follows shema's original design but includes the improvement I implemented to make sure we have a consistent cell 0 selected on both BLK2-5 and BLK1-3 at powerup.

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

Improvement may be needed on the powerup reset system and cell selection reset system.