Sunday, 19 January 2025

Mini VIC Revisited Part 2

In the last post I finished laying out and routing the PCB for the new version of the Mini VIC. I like to leave things for a couple of days if I can, and then go back and check over.

I wanted to check the board dimensions, and a couple of things on the actual schematic.

In order to check the board dimensions, I dug out on old VIC20-CR board. This was one that came in a lot of broken Commodore stuff from ebay. It had either been used as a spares board, or the previous owner had been trying to track down a fault or maybe even trying to turn it into a board with all sockets.

Lots of chips had been removed (badly), and the board to be damaged in several places, so it was now committed to being a parts board. It was still useful as I was able to steal several of the remaining bits myself to save other boards.

Not sure the technique they had been using to remove parts, but some things like the BASIC ROM socket still has all the solder in the holes. Was it "flood the back with molten solder and lever the chip from the front"? I dread to think.

There was a leg of the 7406 still hanging on before I cleaned it up, but several tracks, pads and through hole plating has been lost.

Anyway, it turned out to be ideal in this situation as I was able to remove most of the parts from the ends of the boards.

It actually cleaned up quite well (I should have taken a photo before I started), so I may go on to remove all of the remaining parts and clean up all the solder to make a blank (if damaged) VIC20 PCB.

The dimensions of the PCB had been worked out using a ruler and a micrometer, and a bit of guesswork.

The plan, now I had the board bared back, was to compare this to the 1:1 scale printouts of the PCB.

Here I could see that most of the things were in the right place, but it needed a tweak here and there.


The next task was going back over the schematic to make sure everything was correct.

I had to double check a few things that didn't seem right, such as the Colour RAM chip select line. It comes from the output of a 138, is then inverted, and inverted again. Seems odd to add two unnecessary steps?

On the actual VIC20 schematics, this is split over 3 pages, so I had to pull all of those together to confirm I had actually redrawn the correct things.

It starts on page 2.

Then jumps to page 1.

And finally page 3.

And that does indeed seem to match what I have drawn.

What is going on here is the two modes of operation. In one mode, the 6502 is driving the bus. Ding ding, fares please.

When VIC_PΦ1 is low, the signals on the left of the LS245 are connected to the ones on the right, which means CPU_A8 drives VIC_A8 etc. (the VIC should have stopped driving the bus itself at that point).

This means the inverted /Colour RAM signal is passed through and inverted again to generate /Colour_RAM_CS.

When VIC_PΦ1 is high. The buffers on the 245 are disabled, and the pullup resistor comes into action, making the /Colour_RAM_CS signal go low.

This means the colour RAM chip is always enabled when the VIC is in charge, and only enabled when block 4 is being accessed when the 6502 is in charge.

It is presumably done that way as a pull up is easier to deal with for 74LS logic, or the extra delay was needed, or maybe the CS line needed to be buffered if the inputs on the 2114 RAM chip would be a heavy load?

Either way, it shouldn't be a problem with 74HC series logic, but I may as well leave it like that for now.


The other things I wanted to check was the Character ROM. It isn't clear from the schematic what is going on. All the ones I could find show pins 20 and 21 being marked as "CS1" and "CS2". This would imply active high chip select inputs, both have to be high to enable the chip.

It says 2532, which is an EPROM, but I have only ever seen mask ROMs installed (901460-03).

The 2532 has those pins as marked as PD/PGM and VPP, so they would need to be low and high respectively to enable read mode.

I had initially taken them at their word, and used a NAND gate to convert the two active high signals to give a single active low enable, which is required for the modern EPROM I am using. It wasn't on the original, but since I was using a spare 3 input NAND gate, I also added an active high read signal so it would only be enabled for reads.

But which is it? High + High or Low + High?

Well, I worked through the memory maps to see what it should be. The VIC chip has a 14 bit address bus (and a 12 bit databus), and has several of windows into the full 6502 address bus.

Looking at that table, it makes more sense of the values you enter when setting the locations of RAM, colour RAM and character RAM when configuring the VIC chip at $9005.

You can even see why when you set the character memory to $1C00 (on the 6502 side), you get 128 UDGs in RAM and then the first 128 characters of the font ROM as it loops back around on the VIC side from $3C00-$3FFF to $0000-$03FF.

What is block 0 ($0000-1FFF) to the 6502, is actually $2000-3FFF to the VIC, and block 4 is $8000-9FFF to the 6502 and $0000-$1FFF to the VIC. This means that the character ROM should only be enabled when the VIC_A13 and VIC_A12 are both low. (which is neither of the cases implied by the schematic above).

OK, so I need an OR gate.

There aren't any of those in the design so far, but there are 4 NOR gates. 3 of those are employed to do things with the clocks and read/write signals.

The forth does like it could possibly be stolen.

This is the select lines for the block 0 8K of RAM from $0000-1FFF, including the external 3K on the cartridge port and the internal 5K, which those AND gates now combine to provide on a single RAM chip.

Two of the three enable inputs of the 138 are used. E3 needs to be high to enable any of the outputs. In CPU mode, this is connected to /BLK4 (see above), so will be high when block 0 is to be accessed. In VIC mode, this is VIC_A13. It will be high when the VIC is reading $2000-3FFF in it's address space, which is this block of RAM.

The second input /E1 needs to be low to enable the RAM. For that to be low, SΦ1 needs to be high (the VIC is active) or /BLK0 needs to be low (CPU is accessing block 0).

I wonder......

Here I have used the spare element of the 245 to in theory do the same job. When the VIC is in operation, the 245 is disabled, so the pulldown resistor pulls /E1 low, enabling the chip as required. In CPU mode, that pin is connected to /BLK0, so will be low when that is being accessed and high other times, again as required.

That frees up a NOR gate and an inverter, and as if by magic, that makes an OR gate.

Great, that's all sorted.

But wait, let's just have a look at all of the NOR gates again.

Now every single NOR gate is being followed by an inverter. So I could just replace all of those with OR gates?

I can then get rid of the NOR gates altogether, and swap the 74HC02 for a 74HC32 (which annoyingly has a different pinout). That will leave 4 spare inverters.

But wait!

The other two inverters were sort of pointlessly inverting the colour RAM signal twice, if I got rid of those, I could get rid of the whole 74HC04 chip.

With the HC logic, a pulldown resistor should be fine. So that saves me a whole chip. Nice.


OK, hold on a moment, lots of changes going on here. Maybe a should rein things back a little. This is something I can test when I have a working board on my bench. It may be that some of those multi-chip operations were necessary for timing reasons, so I am a little hesitant to make that much of a change.

I had a look at it again, and realised I had missed an obvious solution.

Chip enable and output enable do slightly different things, chip enable does a lot more during programming. In normal use it is basically a built in OR gate. Both inputs have to be low in order to read the chip. Which as I have already worked out, is exactly what I need.

That's a fairly minimal change, and actually frees up a 3 input NAND gate. I lose the gating with the read signal, but that was never there on the original anyway. (I will try to add that back in the final design)


A couple of tweaks to the schematic and a couple of tweaks to some mounting holes and that is ready (again).

At that point, I ordered the PCBs. Tune into part 3 to see how they came out.


Adverts

You can now get a ZX80 kit for $200.

Sorry, right price, wrong advert.

You can now get a Minstrel 2 kit for $200. 1980s pricing.

Or you can get a Minstrel 3 kit for $200

Patreon

You can support me via Patreon, and get access to advance previews of development logs on new projects and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

Sunday, 12 January 2025

Why does the 1541 disk drive keep spinning?

This is a bit of a strange issue that came up during some recent testing.

It only happens if you load the PRG version of Rodman from a 1541 disk drive onto a VIC20 and run it immediately before the disk spins down.

When you do that, the disk activity light goes out, but the drive keeps spinning. The game runs fine, it is just the disk drive that behaves oddly.

It only if the drive is still spinning, there is not time to type R U N and press RETURN, so it is only automatic starts like the Penultimate Cartridge file browser. I also check it does the same thing if you have the BASIC 4 ROM if you do SHIFT + RUN/STOP and have Rodman as the first program on the disk. It both cases, the game starts immediately after loading.

I decided to wire up the logic analyser and have a look what is going on. Here I have the IEC bus side of Data, Clock and ATN, and the IO chip select line for the VIA chips.

This is the end of loading Rodman.

Looks OK to me.

For comparison, this is the end of loading Bertie the Ball, which does not leave the disk spinning.

I zoomed in a little closer for the screenshot, but it is doing the same thing. The three ATN pulses at the end to ask the drive to stop talking, close the file and release the bus.

Hmm. I was thinking it might be some weird edge case if the file was a multiple of some block size or off by 1 etc.

It was only when I zoomed out that I noticed a difference.

At some point, there is some IO activity and ATN gets asserted again and the drive thinks it is going to be asked to do something so keeps the rust spinning.

This is Bertie the Ball, you can see there is some IO activity, but the IEC lines are unchanged.

I think this might be a similar issue to that of the autofire on Bandits I saw previously.

The problem was with the port A output register on the userport VIA. The pins on there control IEC ATN line output, and are inputs for datasette sense, IEC clock and data and 4 of the 5 joystick directions (don't ask).

The PA7 output drives a 7406 inverter, which will assert the signal (pull the bus low) when PA7 is logic 1.

In Bandit's case, it was writing to that port as part of the initialisation and changing the value of bit 7 to 1. This asserted the ATN signal and because of a previous change to the other signals caused the drive to react, which meant the signals read from port A were different if a drive was connected.

I asked Misfit (the creator of Rodman) if he was writing to $9111, and he was good enough to check and found no writes to that address in his code (or the alternate version at $911F).

Odd.

He sent me the code, which consisted of 7 POKEs, setting up various registers on the two VIAs, but not including $9111.

   POKE(0x911C,0xFE);

   POKE(0x911E,0x7F);

   POKE(0x912E,0x7F);

   POKE(0x9112,0x00);

   POKE(0x9113,0x00);

   POKE(0x9122,0x00);

   POKE(0x9123,0x00);

I zoomed in to the point where ATN was asserted, and I could see those 7 POKEs (it's quite neat when you can actually visualise code happening)


You will see the spacing of those is not quite even. This again is visualisation of code. Due to clever ordering the statements, the compiler is able to optimise out several of the LDA statements where the same value is written to several addresses, and has already been loaded.

Looking at the trace, you can see it is the fifth POKE which causes the problem.

   POKE(0x9113,0x00);

Ah, of course. That is writing to the data direction register for port A, and setting all the pins as inputs.

The ATN out pin, controlled by bit 7, should be an output, as it directly driving the input of a 7406 inverter.

When bit 7 is set as an input, the input of the 7406 buffer will be floating, most lightly read as a 1. In practice, this depends on make, type and age of the VIA, how strong the pullups on the input pins are, and also on the make, type and age of the 7406 if it has an input pullup or what it will consider a logic 1.

This was first spotted by a colleague using Vice with "true drive sounds" on and it continued the "disk spinning" sound after the game had started.

I was testing here with a VIC20-CR and a Mini VIC and a 1541 drive.

The internal pullup in the 6522 most likely means that the ATN signal will be asserted. If this happens before the drive has spun down, it will keep the disk spinning as it thinks it is about to receive a new command.

It probably does this on an SD2IEC as well, but you wouldn't notice as there is no sound.

I tried a few more games, and noticed the same thing on Bolder Dan.

Here there are 20 pokes this time, the 4th one seems to assert clock and / or data, and the 13th asserts ATN.

How to fix this?

Ideally you would set bits 7 as an output and write 0 to those bit 7 in $9111. Both of which should already be the case, so the easiest fix is simply to remove the fifth POKE.

I am not sure this actually needs to be fixed, since it only affects someone using a Penultimate Cartridge and a 1541 disk drive to load a game which was never released on disk, and is already in the Penultimate Cartridge. Normal loads on any device are fine as the drive normally spins down before you have had time to type in R U N and press enter. 


Adverts

You can now get a ZX80 kit for $200.

Sorry, right price, wrong advert.

You can now get a Minstrel 2 kit for $200. 1980s pricing.

Or you can get a Minstrel 3 kit for $200

Patreon

You can support me via Patreon, and get access to advance previews of development logs on new projects and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

Sunday, 5 January 2025

Mini VIC Revisited Part 1

Way back in 2020, I started looking into producing a Mini VIC kit, along the same lines as the Mini PET. Something that was VIC20 compatible but built using modern W65Cxx and 74HC parts.

The trickiest part of that was finding a way to replace the VIC video (and sound) chip. I tried various options to get a microcontroller to be able to generate the video output.

These were looking promising, so I set about designing the Mini VIC board, at this stage with everything apart from the VIC chip replaced. The plan was this would be the test harness for the replacement video chip design.

I wasn't really happy with the way that turned out, I tried to do a few too many things, and it didn't work out as well as I would have liked. In order to save a few chips, I ended up complicating things with 4 way mux chips and things like that.

I also added configurable internal RAM. Whilst that was nice, it further complicated things. When that was enabled, it shouldn't enable the same zones in the cartridge slot etc. And at the end of the day, you will probably be running this with a Penultimate cartridge installed, so it would just be duplicating the 35K expansion anyway.

It sort of worked, but wasn't quite right.

At the time I put the project to one side, waiting until I had a better idea for generating the video.


Roll on 2024, and I have more ideas for generating the video output.

I did spend a while looking at a purely logic based VIC, the Maxi-VIC. Whilst this is viable, I think it worked out something like 80 - 100 logic chips, so was never going to be practical for something like this. (although never say never....)

There is promise of a drop in FPGA based VIC chip replacement, which would solve the problem.

(edit, there are now several FPGA versions in development)

I looked again at the design and decided to roll back several of the changes I had made and go for something closer to a VIC20-CR.

That meant going back to two ROM chips (still one better than the original three ROM chips), and just the standard 5.5K of RAM across two chips (again better than the 5 chips on the VIC20 CR or something like 500 on the 2 pin VIC20*).

* OK, it's 11. But it feels like 500

I was also not happy with my clock optimisation, timing is always a bit of an issue, so I again decided to roll back, at least for the moment.

I am not sure at this stage if I will stick with logic chips or if I will replace a whole load of those with a GAL chip or two. I need to build a revision with standard 74HC logic, at least to start with, I can then try out the GAL and see how viable that is.

Once I had moved things around, I had a lot of space left for whatever solution I come up with.

The timing is a bit complicated. The original 6502 has three clock pins, one input and two outputs.

There are 5-10ns gate delays between the outputs. Φ2 is a buffered version of Φ0, and Φ1 is an inverted version of Φ2.

Vintage systems would feed Φ0 from an oscillator (or sometimes video chip or ULA), and then the rest of the system would use the Φ2 output (or Φ1 for some reason on the BBC if I remember correctly).

The VIC20 was a little different, it has lots of clocks going on. The VIC chip has two clock inputs which must be complimentary versions of each other, and two clock outputs, although only one is used.

The 6502 is fed from an inverted version of one of those (which is what the unused clock output is meant to be ?), and the main system clocks S1 and S2 are generated from ORing Φ0 and Φ2. This gives a slightly longer pulse that either of those on their own.

The VIC20-CR further complicated things by also using Φ1 to gate the VIC R/W signal (handily using up four spare gates and a square inch of space from the schematic above).

For the final Mini VIC, I will be using the modern WDC W65C02S. This does things slightly differently. It still has the two clock outputs, but I found in testing on the early Mini PETs that there was some drift in these outputs over time and that was enough to make things unstable on longer term burn in tests. The datasheet states these should not be used.

I notice they have changed the naming, and what was Φ0 (in) is now Φ2 (in). When I disconnected the system clock of the Mini PET from Φ2 (out) and ran everything from one external clock fed to Φ2 (in), everything was suddenly rock solid stable, and it would run for days on end with no issues.

Trying to fit that into the VIC20's clock arrangement is going to be interesting. I have set the revised board up to the original timings, and with a jumper on pin 1*. I can fit either a 6502 or W65C02S on this board. That should allow me to investigate this further and work out the best implementation going forward.

(* pin 1 is a second ground pin on the 6502, but is frustratingly now an output on the W65C02S. Other differences just need a few extra pullup resistors, but that one is a deal breaker)

I managed to get quite far before I realised I had forgotten decoupling caps. I usually add one per chip, but I noticed there were very few on an actual VIC20, so I was going to see how it went with fewer. In the end I decided to leave space for the usual compliment, and maybe try only fitting some of them (or "Muntzing" a working board to see how many I can get away with).

As always, I like to do a neat PCB layout. This one has lots of different busses, so I tried to arrange the parts to let them flow between the chips.

Also as usual, I routed myself into a corner in the middle of the board (I know what I mean), and had fun trying to sort out the routing for all the logic chips.

But I got there in the end. Not as elegant as I would like, but those may end up mostly replaced by a GAL or two which will make things simpler and neater.

GALs are great for dealing with all the address decoding, and replacing all those 74LS138s. And particularly the 74x133, a 13 input NAND gate, which is no longer in production in either it's 74LS or 74HC form.

I had to replace that with two 74HC21's and a 74HC10. (I was able to use the remaining parts elsewhere so not a complete disaster).

That's all routed now, it should be a drop in replacement for a VIC20 or VIC20-CR, with a few extra nice touches.

Made from all modern parts other than the glaring exception of the VIC chip, but hopefully an FPGA based replacement will drop from the skies at some point.


Adverts

You can now get a ZX80 kit for $200.

Sorry, right price, wrong advert.

You can now get a Minstrel 2 kit for $200. 1980s pricing.

Or you can get a Minstrel 3 kit for $200

Patreon

You can support me via Patreon, and get access to advance previews of development logs on new projects and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.