This video explained the one thing that always confused me with other video card builds. That was how to access memory without conflicting with the cpu. Thank you!
My favourite technique (that isn't just having seperate video RAM) is taken from the BBC Micro. Double clocked RAM. As much as I loved the Beeb I doubt anyone would really be interested in a Dr Matt style recreation but if you're looking at making your own "retro style computer" it's a technique to seriously consider.
Interesting, i like the machines to use the existing software base, which is why i haven't gone too far off script. If you are interested in some other raster generators i've built, have look at dl.acm.org/doi/pdf/10.1145/192161.192192
@@DrMattReganthanks for sharing that. I'm currently on my phone but a quick scan looks very interesting and surprisingly not totally beyond me. Will definitely read it properly later. My comment was more aimed at @GrandpasPlace and others as another example of techniques that were used to solve that problem. I wasn't at all suggesting you change your approach. I absolutely love your vids and I wouldn't want to ruin your enjoyment making them. And I definitely don't think I could tell you how to approach the subjects better.
very ingenious solution for the video output! I did something similar but was somewhat lazy by using a dual port sram by idt to isolate the cpu access from the video raster generator.
Absolutely loving this. Being a ZX clone enthusiast since 15+ years I've been waiting for a TTL based Commodore machine. I guess the C64 is way too complex with it's 1000s of unintended features in the VIC-II/SID, but the VIC20 being a project that seems feasible to not end up with hundreds of chips.
Wonderful. We'll see about a C64, but the VIC-20 is simpler and lower hanging fruit. I'm still planning to replace the 6502 and VIAs in this build as well.
@@DrMattRegan Did you decide yet on how low level/accurate you want to go? Specifically regarding raster based effects or demos that use undocumented features/bus noise.
@@1337Shockwav3 don’t know how far I’ll go with undocumented features, I’m more seriously thinking about making it accurate to the VIC specifications, but I might pass the batton onto someone else if they want to extend it to the undocumented ones.
@@DrMattRegan That's probably the approach that makes most sense and quite frankly is what most ZX clones do as well. There are very few machines that support reading attributes back from the screen, which is unintended behaviour of the Sinclair made ones turned into a feature used by less than 10 programs - simply because it just adds to the complexity, while adding very little to the overall functionality. I'd assume if you can run 95% of all popular games it will be more than enough and as you said - a base for further improvements in case someone *really* wants to do a deepdive. As said - really looking forward to this. You're aware of the MOnSter 6502 and J-CIA projects, right?
I'm more familiar with MOnSter 6502 than J-CIA, but moving forward, i'll probably use the Turing6502 ua-cam.com/play/PLjQDRjQfW-84j-jLvrbEeDvGl0QrhX9p7.html and the SAP6502 is also an option ua-cam.com/play/PLjQDRjQfW-85S5QkX8wZbkqichM6TLYYt.html Check them out if you haven't seen them yet. I personally like the Turing6502 better and it has fewer chips.
Dazzling as always. One of the simpler things you glided over is using an 8:1 Mux to synthesize any 4-bit function. I don't know why but it delights every time I get a chance to apply it.
Re your aside at 3:40 - the VIC buffers the bitmap internally, also there are several other stages, clocked by the two phases of the pixel cloc, before a pixel reaches the output stage. Then after that there is probably an additional delay because the output stage uses several inverters. I believe the sequence goes more or less like this - character / colour read (PHI1) - CPU access (PHI2) - bitmask read (PHI1)
Interesting. I don’t think I articulated the question very well, but what I was wondering is whether (1) the bitmap data is loaded directly into the shift register and serialised, or (2) is it stored in another register first then transferred into the shift register to be serialised. This is the extra register I was talking about. So I think you are saying 2, With the my current design the serialised data goes through a couple more pipeline stages before it’s displayed. So it was more about when it’s loaded into the shift register.
One of the interesting things I've learned from this video series is that you can characterise almost all 80s and a fair few 90s machines by having 2-16 states which are statically allocated to either the CPU or the graphics circuitry. Maybe the Jay Miner designed Atari 8 bit and Commodore Amiga are bit more flexible but for the Vic 20, C64, Spectrum and Atari ST it seems like someone worked it out on a piece of paper and the machine was hardwired to do it that way.
Yep, you can also build the CPU with a state machine and some memory. If you haven't seen it, you might want to watch this series: ua-cam.com/video/gHU8whQP3Rg/v-deo.html Hint: this is where i plan going!
I always wondered what the second chip select line did on the VIA. In my design I fully decoded RAM using a 3 to 8 decoder and used a single chip selection line. That second line looks handy. Obviously I should have read the data sheet more carefully.
Yeah, i guess every dollar saved is multiplied by a couple of million for commodore, so it's a priority for them, but not us for one off prototype builds.
I have been thoroughly enjoying your various series, thank you very much. Indeed I think I'm going to have to convert your design to a PCB layout when it's done, with your blessing. I'm curious to know how you are going to handle RAM upgrades - of course you will have plenty of memory to reproduce a fully expanded VIC-20, but as the memory map moves about depending on installed RAM and software expects this behavior, I guess you will need to handle this somehow. PS: It may be you have different plans for the future, but if I might make another suggestion for a future system to recreate might I suggest the Acorn Atom? I can imagine lots of people in the UK would be interested, and the Atom was a system with all sorts of expansion options that a hobbyist might enjoy attempting to add to your 'base' design. Also the usually 1mhz CPU was capable of running at higher speeds with common hacks, which might be 'fun' to show how to implement in a TTL design. (Oh, and it would be nice that you'd be likely making a better fist of Acorn's shockingly poor colour add-on design!)
Certainly, go ahead and build a PCB. Generally i'll run with the full complement on RAM, but if i want to disable the RAM in 8K blocks, i can use the 74HC151, and just set the appropriate input for a block to zero. This places ROM (usually empty) in that memory slot. I'll have a look at the Acorn Atom, but i'm not super familiar with it. I want to replace the 6502 next in this series with TTL logic in this build.
Great video, thank you. Fascinating to see it all come together and be functional in stages. Looking forward to the next video and some demonstrations. Do you also have sound? LaserZone by Llamasoft has great sound. Robotic Liberation Demo (Viznut audio waveforms for speech) Star Defence also good sound and 2 speed modes. All of these push the sound beyond the normal slightly out of tune 3 channels plus noise. Most Llamasoft games really push the sound for Awesome Sonix! Thanks to Yak.
Thanks for that. I don’t have sound yet, but I plan to do it on a second board. Think I’ll use some 161s for each voice. Still trying to decide if I can get away with a low pass filter, or if I’ll need sine wave table and a DAC
@@DrMattRegan Excellent. Really impressed with the whole concept of how you are recreating the best computer. Thank you for sharing this and the effort you put in.
When you do the colour circuit, any chance of a side quest showing how to implement the Plus4's 121 colours ? as you have 8bits of colour data available in this scheme. A hybrid VIC20 with 121 colours would be interesting, you would have to call it the Plus2, & a C64 implementation would be even cooler.
Where would one find those older style keyboards that work directly with the Vic20/C64/Apple ][ ? Do you have a Perfboard video series on making one? I'm in a smaller island town in Canada so the famous USA swap meets are not an option.
Hi Matt, is there a way to use more memory slots of the sram. Say a multiplexer with a buffer that held the data value in the fiom memory timing slot to present it to the processor thoughout it's timing period while the other slots are used? It's a shame that Commodore Mos could shrink down the logic in this circuit into the vic or a mcu and add to it with faster better sram, as they had a fab and design section. 512 pixel 16 colour probably wasn't too far off being possible for a Vic 2. Certainly just character mode. Another interesting one is the Mattel Aquarius, which made good use of game character graphics set. Now for 256 pixels at 256 colours with 256 sprites. (I am kidding, but it's great to see the Vic's colours again 😀).
Yep. One of the unfortunate things about the 6502 design is that they didn't think of a larger address space. I guess they never figured it would have the shelf life it did. But just a simple banking register internally and some control logic, very minimal, just so there was a standardized way of bank switching. The VIC is an interesting chip, clearly the machine was designed with games cartridges in mind (hence the 5k memory), but it's biggest drawback is not using DRAM. Obviously, they fixed that pretty quickly in the Commodore 64.
@DrMattRegan I was meaning the timing slots. So that the cpu read activates a read tgrough multiplexer held by the buffer in the first timing slot, leaving the other 7 slots free? As for sram, its disadvantage is cost, its advantages is higher speed possible and higher soeed random acess. So, for a cartridge system the ability to render to screen for complex graphics elements could have been an advantage (sram they could have rendered a character with 4 distinct colours, and in a multi colour mode like the 64, 4 per higher resolution character. Those graphics also being ripped off cartridges. With dram, it's likely a higher cost spend varrient (if available) or mu,ti banking to get the data rate. They had a factory but didn't take advantage. With the 64 though, the amount of memory was the real big advantage of using lower cost dram. But as you are saying about dram bankswitching, you are right. I proposed a logical design that virtually makes banked segments like paged memory. Lots of it, where you can swap in the segments of code needed and screen data, with enough parrallel banks for higher data rate graphic modes. But, back in those days the expensive bling words like Blitter and such forth, made us forget other cheaper approaches (without mysterious Bit Planes, which turned out unnessacary).
So, yeah you could probably use 3 of the 8 slots for other things like DMA etc or more colour bits per pixel. I personally tend to avoid modifying so much that there is no software out there that will run on it though.
Excellent, i hope part of the appeal is to see the build progress for those that don't have the time to do it themselves. A bit like grand designs, i like seeing the houses built, but i don't the time (or patience/skills myself) to build the house.
@@DrMattRegan I like to keep things minimal to an extreme so I've taken some thinking time(...since 2022) to decide how I'll go from monochrome to 8+ bit color on my "bigger" SBC. Afraid I can't go with a faster RAM like you do but I see the appeal. Curious to see how you get it all the way - and sound, not to forget that part!
Hey Matt, loving this series. Thanks. I have a question, the section at 12:56 where you describe the way the memory map works seems incomprehensible to me. I suspect that the diagram on the right (A15:A14 / A13:A12) is some kind of truth table, but it seems inverted to what I would have thought, and the "legend" of EPROM Enable bar adds to my confusion. Can you tell me what this type of diagram is called so I can go look it up, please?
Yep, it’s a karnaugh map - there are quite a few UA-cam videos on them. It’s a way of figuring out what logic you need for a 4-input circuit, each highlighted group is an AND gate. These are all ORed together. Problem is, they tend to use a lot of chips, thus the 74HC151 is an easier solution. The idea is that a 1 represents RAM and a 0 Represents ROM
Ahhh! Thanks, @@DrMattRegan! I could _nearly_ tell that that was what you were intending to depict, but I couldn't map the bit patterns I was seeing to the words. The 1=RAM, 0=ROM explanation clears that up for me. Will now go study Karnaugh maps. Thanks again!
No problem, we have 2 bits along the top and 2 bits down the side. The trick is that the ordering is 00, 01, 11, 10. That's so we can group up the cells so they can be implemented with an AND gate.
Wonderful job explaining the workings! A couple of things I noticed... I see that the addresses for the VIA's are only partially decoded (same as in the actual VIC-20), so, for example, at address $9030 I'm thinking that both VIA's will try to respond and the result will be garbage. Is this an issue that should be considered? Second, and I have been caught by this one, I see you haven't incorporated the clock signal into the chip select for the RAM. Not doing this could cause random writes to the RAM which would be undesirable to say the least. The explanation of why this is necessary is shown by Ben Eater in this video: ua-cam.com/video/i_wrxBdXTgM/v-deo.html (start around 22:00 if you don't want to watch the whole thing.) I'm thinking this would apply to this build as well but maybe that's in an upcoming video. Again, a wonderful video, can't wait for the next one!
Thanks for that. Yep, 9030 will cause a conflict, but i imagine that everyone who write software for the VIC-20 would avoid this. Technically someone may use this, so at least we'll act the same as the real machine. Well, spotted on the clock signal. On the prototype i do actually run the R/W signal through an OR gate with clockbar. I just forgot to update the schematic between revisions (which tends to happen when i'm rushing to get a video out before the weekend).
Legendary .. and that issue at the end... multicolour bitmap mode? Always that mixed 2 bit per pixel mode used to stuff me up with the double height/width characters.
Thanks Andy. Yep, the choplifter at the end is using 8x16 characters, which I haven’t corrected for properly in the raster generator. The bit ordering isn’t what I was expecting for double height characters.
@@DrMattRegan So many people have utilised "bugs as features" in the VIC II Chip for the C64 in the demoscene, but the 6560 and 6561 remain pretty under-utilised for extreme hack-effects. The good news is it makes your life easier in building a perfect reverse engineered masterpiece. I did join the list of people who managed to coax a workable 40x20 terminal display in monochrome out of the 6561 by mucking with interlace and raster registers in bitmap mode but it didn't work well - too slow and the fact NTSC machines used the 6560 as you have reverse engineered meant it wasn't compatible. Hence - my move over to coding the BBC Micro and eventually ARM based Archimedes.
Ha ha, yep. I guess my aim at this stage is to get "most" of the games working. I'll probably skip the light-pen and paddle. I've got space in the raster EPROM for maybe 16 different video modes, but beyond that i'll need to add extra hardware. Many games that i've looked at use 22x23 in normal mode and 22x22 for 8x16 character mode, but there is some variation. I've been trying to avoid a 1:1 copy of the chips, i want to be more of looking at it (6560) from a different angle and describe how it works as i go along.
@@DrMattRegan thank you. The vic 20 is a personal favorite. And vic chips are becoming too expensive. What form factor will the pcb be if you have a idea on your head about it ?
I am building a homebrew m68k on a prefboard. But my wiring is not as neat as yours. Don't suppose you could do a short video just showing how you wire, the equipment you use, wire size, etc?
If I simulate, I tend to use C/C++ so I can interface the simulation with the real circuit via an arduino. I haven’t used a simulator for this design though.
This video explained the one thing that always confused me with other video card builds. That was how to access memory without conflicting with the cpu. Thank you!
Glad it helped!
My favourite technique (that isn't just having seperate video RAM) is taken from the BBC Micro. Double clocked RAM. As much as I loved the Beeb I doubt anyone would really be interested in a Dr Matt style recreation but if you're looking at making your own "retro style computer" it's a technique to seriously consider.
Interesting, i like the machines to use the existing software base, which is why i haven't gone too far off script. If you are interested in some other raster generators i've built, have look at dl.acm.org/doi/pdf/10.1145/192161.192192
@@DrMattReganthanks for sharing that. I'm currently on my phone but a quick scan looks very interesting and surprisingly not totally beyond me. Will definitely read it properly later.
My comment was more aimed at @GrandpasPlace and others as another example of techniques that were used to solve that problem. I wasn't at all suggesting you change your approach. I absolutely love your vids and I wouldn't want to ruin your enjoyment making them. And I definitely don't think I could tell you how to approach the subjects better.
very ingenious solution for the video output! I did something similar but was somewhat lazy by using a dual port sram by idt to isolate the cpu access from the video raster generator.
Cool, thanks
Absolutely loving this. Being a ZX clone enthusiast since 15+ years I've been waiting for a TTL based Commodore machine. I guess the C64 is way too complex with it's 1000s of unintended features in the VIC-II/SID, but the VIC20 being a project that seems feasible to not end up with hundreds of chips.
Wonderful. We'll see about a C64, but the VIC-20 is simpler and lower hanging fruit. I'm still planning to replace the 6502 and VIAs in this build as well.
@@DrMattRegan Did you decide yet on how low level/accurate you want to go? Specifically regarding raster based effects or demos that use undocumented features/bus noise.
@@1337Shockwav3 don’t know how far I’ll go with undocumented features, I’m more seriously thinking about making it accurate to the VIC specifications, but I might pass the batton onto someone else if they want to extend it to the undocumented ones.
@@DrMattRegan That's probably the approach that makes most sense and quite frankly is what most ZX clones do as well. There are very few machines that support reading attributes back from the screen, which is unintended behaviour of the Sinclair made ones turned into a feature used by less than 10 programs - simply because it just adds to the complexity, while adding very little to the overall functionality.
I'd assume if you can run 95% of all popular games it will be more than enough and as you said - a base for further improvements in case someone *really* wants to do a deepdive.
As said - really looking forward to this.
You're aware of the MOnSter 6502 and J-CIA projects, right?
I'm more familiar with MOnSter 6502 than J-CIA,
but moving forward, i'll probably use the
Turing6502
ua-cam.com/play/PLjQDRjQfW-84j-jLvrbEeDvGl0QrhX9p7.html
and the SAP6502 is also an option
ua-cam.com/play/PLjQDRjQfW-85S5QkX8wZbkqichM6TLYYt.html
Check them out if you haven't seen them yet.
I personally like the Turing6502 better and it has fewer chips.
Can't wait to next part of the VIC 20 built !
Great, thanks for the feedback!
This is such a cool series.
Thanks for that!
Dazzling as always. One of the simpler things you glided over is using an 8:1 Mux to synthesize any 4-bit function. I don't know why but it delights every time I get a chance to apply it.
Glad you like it. Yep, its a cool trick with the 74HC151s
Re your aside at 3:40 - the VIC buffers the bitmap internally, also there are several other stages, clocked by the two phases of the pixel cloc, before a pixel reaches the output stage. Then after that there is probably an additional delay because the output stage uses several inverters. I believe the sequence goes more or less like this
- character / colour read (PHI1)
- CPU access (PHI2)
- bitmask read (PHI1)
Interesting. I don’t think I articulated the question very well, but what I was wondering is whether (1) the bitmap data is loaded directly into the shift register and serialised, or (2) is it stored in another register first then transferred into the shift register to be serialised. This is the extra register I was talking about. So I think you are saying 2,
With the my current design the serialised data goes through a couple more pipeline stages before it’s displayed. So it was more about when it’s loaded into the shift register.
Thanks, I enjoy all your videos. I look forward to seeing how this one goes, though I never had a VIC-20 and I'm not very familiar with the hardware.
Thanks for the feedback. VIC-20 was a great little machine for it's time, the commodore 64 makes more sense when viewed from the lens of the VIC-20.
Love it! Thank you!
Great, enjoy!
Great explanation, can't wait to see the next part
Thanks for watching! Working on it this evening!
One of the interesting things I've learned from this video series is that you can characterise almost all 80s and a fair few 90s machines by having 2-16 states which are statically allocated to either the CPU or the graphics circuitry. Maybe the Jay Miner designed Atari 8 bit and Commodore Amiga are bit more flexible but for the Vic 20, C64, Spectrum and Atari ST it seems like someone worked it out on a piece of paper and the machine was hardwired to do it that way.
Yep, you can also build the CPU with a state machine and some memory. If you haven't seen it, you might want to watch this series:
ua-cam.com/video/gHU8whQP3Rg/v-deo.html
Hint: this is where i plan going!
This is fantastic, such a cool series and one I hope I'll be able to follow in hardware, so much useful and well presented knowledge.
Enjoy, glad you're getting some value from it.
At last! Looks like I can get my old wire wrap gun out of the draw! Everyone has to have a hobby right? Keep up the great work!
Excellent, have a go!
@@DrMattRegan but what I saw was a Rockwell 65F11/12 and something running Rockwell Forth. Yes, I am a nerd. DON'T JUDGE ME!
@@asteriondaedalus6859 aren’t they the 64 pin quad pack monsters?
@@DrMattRegan They are at their heart a 6502 with benefits (really a 6511). Never mind me, it's just what popped into my head 🤪
Отличный контент, спасибо.
Thanks for that.
I am arranging to have this video series sent to Albert Charpentier, the inventor of the VIC chip.
Cool, it would be great to have his perspective. Thanks!
I always wondered what the second chip select line did on the VIA. In my design I fully decoded RAM using a 3 to 8 decoder and used a single chip selection line. That second line looks handy. Obviously I should have read the data sheet more carefully.
Yeah, i guess every dollar saved is multiplied by a couple of million for commodore, so it's a priority for them, but not us for one off prototype builds.
Love... fantastic serie.
Glad you like it, thanks for the feedback.
My 6502 project has been stalled for so long, I may need to start from scratch.
Just pick up the soldering iron, it's fun when they work.
Awesome stuff! Thank you very much! 🍀
Thanks for the feedback!
Facinating, thank you very much.
Glad you enjoyed it!
I have been thoroughly enjoying your various series, thank you very much. Indeed I think I'm going to have to convert your design to a PCB layout when it's done, with your blessing.
I'm curious to know how you are going to handle RAM upgrades - of course you will have plenty of memory to reproduce a fully expanded VIC-20, but as the memory map moves about depending on installed RAM and software expects this behavior, I guess you will need to handle this somehow.
PS: It may be you have different plans for the future, but if I might make another suggestion for a future system to recreate might I suggest the Acorn Atom? I can imagine lots of people in the UK would be interested, and the Atom was a system with all sorts of expansion options that a hobbyist might enjoy attempting to add to your 'base' design. Also the usually 1mhz CPU was capable of running at higher speeds with common hacks, which might be 'fun' to show how to implement in a TTL design.
(Oh, and it would be nice that you'd be likely making a better fist of Acorn's shockingly poor colour add-on design!)
Certainly, go ahead and build a PCB. Generally i'll run with the full complement on RAM, but if i want to disable the RAM in 8K blocks, i can use the 74HC151, and just set the appropriate input for a block to zero. This places ROM (usually empty) in that memory slot.
I'll have a look at the Acorn Atom, but i'm not super familiar with it. I want to replace the 6502 next in this series with TTL logic in this build.
Great video, thank you. Fascinating to see it all come together and be functional in stages. Looking forward to the next video and some demonstrations.
Do you also have sound?
LaserZone by Llamasoft has great sound.
Robotic Liberation Demo (Viznut audio waveforms for speech)
Star Defence also good sound and 2 speed modes.
All of these push the sound beyond the normal slightly out of tune 3 channels plus noise.
Most Llamasoft games really push the sound for Awesome Sonix! Thanks to Yak.
Thanks for that. I don’t have sound yet, but I plan to do it on a second board. Think I’ll use some 161s for each voice. Still trying to decide if I can get away with a low pass filter, or if I’ll need sine wave table and a DAC
@@DrMattRegan Excellent. Really impressed with the whole concept of how you are recreating the best computer. Thank you for sharing this and the effort you put in.
When you do the colour circuit, any chance of a side quest showing how to implement the Plus4's 121 colours ? as you have 8bits of colour data available in this scheme. A hybrid VIC20 with 121 colours would be interesting, you would have to call it the Plus2, & a C64 implementation would be even cooler.
Interesting thought. I'm thinking of going on to a C64, but first i want to replace the 6502 with TTL logic as well in the VIC-20.
Where would one find those older style keyboards that work directly with the Vic20/C64/Apple ][ ? Do you have a Perfboard video series on making one? I'm in a smaller island town in Canada so the famous USA swap meets are not an option.
Umm, this keyboard was from a non-functional VIC-20 i got on Ebay. There are still a few around.
Hi Matt, is there a way to use more memory slots of the sram. Say a multiplexer with a buffer that held the data value in the fiom memory timing slot to present it to the processor thoughout it's timing period while the other slots are used?
It's a shame that Commodore Mos could shrink down the logic in this circuit into the vic or a mcu and add to it with faster better sram, as they had a fab and design section. 512 pixel 16 colour probably wasn't too far off being possible for a Vic 2. Certainly just character mode. Another interesting one is the Mattel Aquarius, which made good use of game character graphics set.
Now for 256 pixels at 256 colours with 256 sprites. (I am kidding, but it's great to see the Vic's colours again 😀).
Yep. One of the unfortunate things about the 6502 design is that they didn't think of a larger address space. I guess they never figured it would have the shelf life it did. But just a simple banking register internally and some control logic, very minimal, just so there was a standardized way of bank switching.
The VIC is an interesting chip, clearly the machine was designed with games cartridges in mind (hence the 5k memory), but it's biggest drawback is not using DRAM. Obviously, they fixed that pretty quickly in the Commodore 64.
@DrMattRegan I was meaning the timing slots. So that the cpu read activates a read tgrough multiplexer held by the buffer in the first timing slot, leaving the other 7 slots free?
As for sram, its disadvantage is cost, its advantages is higher speed possible and higher soeed random acess. So, for a cartridge system the ability to render to screen for complex graphics elements could have been an advantage (sram they could have rendered a character with 4 distinct colours, and in a multi colour mode like the 64, 4 per higher resolution character. Those graphics also being ripped off cartridges. With dram, it's likely a higher cost spend varrient (if available) or mu,ti banking to get the data rate. They had a factory but didn't take advantage. With the 64 though, the amount of memory was the real big advantage of using lower cost dram.
But as you are saying about dram bankswitching, you are right. I proposed a logical design that virtually makes banked segments like paged memory. Lots of it, where you can swap in the segments of code needed and screen data, with enough parrallel banks for higher data rate graphic modes. But, back in those days the expensive bling words like Blitter and such forth, made us forget other cheaper approaches (without mysterious Bit Planes, which turned out unnessacary).
So, yeah you could probably use 3 of the 8 slots for other things like DMA etc or more colour bits per pixel. I personally tend to avoid modifying so much that there is no software out there that will run on it though.
@DrMattRegan You can get by with slower sram, or people could program it for fun.
Thanks again Matt.
Good job! I'm too lazy to make my builds compatible with anything :) (almost anyway)
Excellent, i hope part of the appeal is to see the build progress for those that don't have the time to do it themselves. A bit like grand designs, i like seeing the houses built, but i don't the time (or patience/skills myself) to build the house.
@@DrMattRegan I like to keep things minimal to an extreme so I've taken some thinking time(...since 2022) to decide how I'll go from monochrome to 8+ bit color on my "bigger" SBC.
Afraid I can't go with a faster RAM like you do but I see the appeal.
Curious to see how you get it all the way - and sound, not to forget that part!
Hey Matt, loving this series. Thanks. I have a question, the section at 12:56 where you describe the way the memory map works seems incomprehensible to me. I suspect that the diagram on the right (A15:A14 / A13:A12) is some kind of truth table, but it seems inverted to what I would have thought, and the "legend" of EPROM Enable bar adds to my confusion. Can you tell me what this type of diagram is called so I can go look it up, please?
Yep, it’s a karnaugh map - there are quite a few UA-cam videos on them. It’s a way of figuring out what logic you need for a 4-input circuit, each highlighted group is an AND gate. These are all ORed together. Problem is, they tend to use a lot of chips, thus the 74HC151 is an easier solution. The idea is that a 1 represents RAM and a 0 Represents ROM
Ahhh! Thanks, @@DrMattRegan! I could _nearly_ tell that that was what you were intending to depict, but I couldn't map the bit patterns I was seeing to the words. The 1=RAM, 0=ROM explanation clears that up for me. Will now go study Karnaugh maps. Thanks again!
No problem, we have 2 bits along the top and 2 bits down the side. The trick is that the ordering is 00, 01, 11, 10. That's so we can group up the cells so they can be implemented with an AND gate.
Very nice
Thanks
Wonderful job explaining the workings! A couple of things I noticed... I see that the addresses for the VIA's are only partially decoded (same as in the actual VIC-20), so, for example, at address $9030 I'm thinking that both VIA's will try to respond and the result will be garbage. Is this an issue that should be considered?
Second, and I have been caught by this one, I see you haven't incorporated the clock signal into the chip select for the RAM. Not doing this could cause random writes to the RAM which would be undesirable to say the least. The explanation of why this is necessary is shown by Ben Eater in this video: ua-cam.com/video/i_wrxBdXTgM/v-deo.html (start around 22:00 if you don't want to watch the whole thing.) I'm thinking this would apply to this build as well but maybe that's in an upcoming video.
Again, a wonderful video, can't wait for the next one!
Thanks for that. Yep, 9030 will cause a conflict, but i imagine that everyone who write software for the VIC-20 would avoid this. Technically someone may use this, so at least we'll act the same as the real machine.
Well, spotted on the clock signal. On the prototype i do actually run the R/W signal through an OR gate with clockbar. I just forgot to update the schematic between revisions (which tends to happen when i'm rushing to get a video out before the weekend).
Legendary .. and that issue at the end... multicolour bitmap mode? Always that mixed 2 bit per pixel mode used to stuff me up with the double height/width characters.
Thanks Andy. Yep, the choplifter at the end is using 8x16 characters, which I haven’t corrected for properly in the raster generator. The bit ordering isn’t what I was expecting for double height characters.
@@DrMattRegan So many people have utilised "bugs as features" in the VIC II Chip for the C64 in the demoscene, but the 6560 and 6561 remain pretty under-utilised for extreme hack-effects. The good news is it makes your life easier in building a perfect reverse engineered masterpiece.
I did join the list of people who managed to coax a workable 40x20 terminal display in monochrome out of the 6561 by mucking with interlace and raster registers in bitmap mode but it didn't work well - too slow and the fact NTSC machines used the 6560 as you have reverse engineered meant it wasn't compatible. Hence - my move over to coding the BBC Micro and eventually ARM based Archimedes.
Ha ha, yep. I guess my aim at this stage is to get "most" of the games working. I'll probably skip the light-pen and paddle. I've got space in the raster EPROM for maybe 16 different video modes, but beyond that i'll need to add extra hardware. Many games that i've looked at use 22x23 in normal mode and 22x22 for 8x16 character mode, but there is some variation.
I've been trying to avoid a 1:1 copy of the chips, i want to be more of looking at it (6560) from a different angle and describe how it works as i go along.
This is so very cool. Would you be releasing a pcb board we can order to make this ?
Yeah, there are some thoughts around a PCB. After i replace the 6502 with TTL logic and finalize on a design i might do one then.
@@DrMattRegan let me buy one when you are ready. Is there a waiting list for it?
Sure, nothing formal in place yet.
@@DrMattRegan fair enough. This work amd your spectrum are top notch. Keep up the amazing work.
@@DrMattRegan thank you. The vic 20 is a personal favorite. And vic chips are becoming too expensive. What form factor will the pcb be if you have a idea on your head about it ?
I am building a homebrew m68k on a prefboard. But my wiring is not as neat as yours. Don't suppose you could do a short video just showing how you wire, the equipment you use, wire size, etc?
Good luck with the build. I’ll go over the build details in the next one.
did you try to simulate in Altium or Proteus?
If I simulate, I tend to use C/C++ so I can interface the simulation with the real circuit via an arduino. I haven’t used a simulator for this design though.
Copy all this into a single FPGA at conclusion?
Maybe, although i think i'll forced to use an FPGA if i move forward to the commodore 64. Might save it for that.
man my 650 project is halted from past 4 months I really wanna start again 🥺
Have a crack at starting it again!