I was using the Stack Computer Products IEEE-488 Cartridge, a fairly simple design, more straightforward than the official Commodore one, but not as minimal as the MSD one. I haven't been able to find any more info on that, other than a single photo, so I'm sticking with the stack for the moment.
The Stack cartridge has an usual driver arrangement for the IEEE-488 bus, with standard TTL chips rather than dedicated IEEE-488 drivers like the MC3446 or 75160/161.
I reverse engineered this design to see what was going on. There is a 2716 2K ROM and a 6522 VIA. The 6522 is connected to the IO2 address range (9600-9BFF). Port A was wired to the eight data lines on the IEEE-488 bus, via a 74LS642, an inverting octal bus transceiver with open collector outputs (n.b. note that says, 'inverting', may be important later).
Port B of the 6522 was taken up with the control lines, driven via 7438 2 input NAND gates with open collector outputs and read via 74LS125 bus buffers. A 74LS00 was used to limit the ROM address range to A000-AFFF (the bottom of block 5). There was also a diode OR gate feeding CB0 from the DAV & IFC signals.
I've been considering trying to fit a PET microSD, a version of this IEEE-488 cartridge and also a set of ROM and RAM into a single cartridge. I've been doing that bit by bit, trying different options and the ROM and RAM versions are working well, with the new menu driven no DIP switch version coming on well.
Rather than duplicate the design, I decided to reduce it down and use standard 75160/161 IEEE-488 bus drivers as things like the 74LS642 are difficult to get hold of (and more than double the price of the 75161).
I also added 32K of RAM under the ROM chip to make this more useful, since without it you can only load programs into the internal RAM.
Testing the new cartridge. The RAM was fine. The ROM was fine. Talking to the 6522 was working fine. Talking to the IEEE-488 bus wasn't.
Testing with my IEEE-488 diagnostics board confirmed the problem, comparing the outputs on the LEDs when sending the same commands to the 6522 on the Stack and my new board showed the outputs were inverted. Sending 00 turned all the LEDs on the databus off on the my board. Sending FF turned them all on.
On the Stack board, 00 was all on, FF was all off. I'm allowed one mistake, right? a 'Partial Success' as a colleague of mine used to say. This is something that could be fixed in hardware, add some inverters (or even revert to the original design). It could also be fixed in software by inverting (or removing inversion if already there). I was trying to avoid modifying the original code, although it's only 2K, so I had considered relocating it to live in the 3K gap in block 0 that is generally unused when 8K or more RAM is added. Back to the drawing board.
2022 Update: I gave up with the IEEE-488 cartridge in the end, the requirement for a ROM means it is always going to take up space that might be needed for the programs you want to load, so best just stick with an SD2IEC for the moment.
This version expands on the previous version by adding 4 pins to each of the
chips. The RAM is upgraded from a 62256 (32Kx8) to a 621024 (128Kx8), and the
ROM from 27C512 (64Kx8) to 27C040 (512Kx8). To control this, the GAL has been
upgraded from a 16V8 to a 22V10.
I've upgraded the PCB to have gold plated edge connectors, for better contact
and I've added some large holes to the board (can you add a hole? OK, I've
removed some hole shaped sections). This makes the routing the tracks more a
challenge, but fits around the pillars in some cartridge cases. This allows the
board to fit into an original cartridge case with no modification.
Here it's installed in a nicely yellowed spare Pirates Cove. The lack of the
apostrophe is annoying, I guess they couldn't decided if it should that be
Pirate's Cove (the Cove of a Pirate) or Pirates' Cove (the Cove of the Pirates).
The game itself says 'Pirate Adventure', I guess that was too many letters to
fit on. (Update: the box says Pirate Cove).
Note the 'Don't forget' label
on the top of the original label, you'll need that later.
The DIP switches to control the mode and the reset switch poke out the top of
the cartridge. You can change mode and press reset without removing the
cartridge or powering off the VIC20.
There's 9 DIP switches there, quite a lot of modes. This is due to the very odd
way the VIC20 addresses the cartridge slot. It's quite clever in many ways, as
little or no address decoding is required for most cartridges. Decoded select
lines are available for the various blocks of memory and I/O:
RAM1 0400-07FF (1K)
RAM2 0800-0BFF (1K)
RAM3 0C00-0FFF (1K)
BLK1 2000-3FFF (8K)
BLK2 4000-5FFF (8K)
BLK3 6000-7FFF (8K)
BLK5 A000-BFFF (8K)
IO2 9800-9BFF (1K)
IO3 9C00-9FFF (1K)
That was designed so you could use up to 3 pairs of 2114 chips controlled by
RAM1, 2 and 3 to give a 3K expansion. This fits into a gap in the internal memory
in what would be block 0 (0000-1FFF). If you add RAM here, the VIC20 shows 6655
bytes available. If you add any more RAM, this 3K isn't counted any more. If you
add RAM to blocks 1, 2 and 3, you can add up 24K of RAM, and the VIC will show
it's maximum of 28159 bytes available. You can add RAM in block 5, the VIC
won't count this, but it can be used to load in cartridge ROM images from disk.
Here is a memory test program I think I got from an ebay listing (?) which tests
which blocks are present.
The first version of this board had a 32K RAM chip, with this I could add
3K + 8K +8K + 8K, or 8K + 8K + 8K + 8K, but I couldn't
have all the blocks filled, 3K + 8K +8K + 8K + 8K. I didn't think
anything would need this, but it turns out the VIC20 port of Doom does, so I
have upgraded the RAM chip to be able to do this. The extra 3K means I had to
switch to a 128K chip, even through almost 3/4 of it won't be used. I could have
achieved this with a 32K chip and an 8K chip (or even 6 2114's), but
aesthetically, it balances the larger 32 pin ROM chip, and it turns out the 128K
chips is not only cheaper than the 32K chip + the 8K chip, it is actually
cheaper than either of them individually. Now you can play Doom if you like.
The RAM is complicated then, but the ROM side must be easier? Well, sort of. If
there is a ROM in block 5, the VIC will run it. On the first revision of the
board, I had a choice of 8 8K ROM images that would appear in block 5 and run.
This was great, but limited the choice of cartridges. Many games needed more
than 8K of ROM, so installed a ROM chip in one of the other blocks. With many of
the Commodore cartridges, such as Defender and Robotron, this was 8K on block 5
and 8K in block 3. Now you can play Ms. Pac Man if you like.
The great thing about standard is there are so many to choose from. Atari
decided they would do things differently, and when they released Centipede and
Dig Dug etc. they had ROMs in block 5 and block 1. I support that as well, so
you can play Donkey Kong if you like.
That's three different ROM configurations, 5, 3+5, 1+5. Any more? Well, yes, for
the five Scott Adams text adventure cartridges, they went for ROMs in blocks 2
and 3. Why? - who knows. (Update: apparently this was due to lack of
space, no autostart saved 128 bytes - see
an interview with Scott Adams). With no ROM in block 5, these do not automatically start, hence the
'Remember to type SYS 32592' label on the cartridge. I've supported those as
well. Adventureland anyone?
I'm not sure if I've shot myself in the foot adding all these modes. it does make for a lot of DIP switches. The first 4 control the ROM and RAM mapping
modes,
Those are split into 4, the first is 8K blocks, the second is 8K blocks plus the
initial 3K. Third comes just ROMs and finally ROMs with RAM in the gaps. Yes,
another configuration, the Super Expander and Diagnostics cartridges have ROM in
block 5 and 3K RAM.
The last 5 DIP switches select which ROM images to load, the high address bits of the
ROM. The ROM socket can take 28 or 32 pin ROMs, anything from a single ROM
image in a 27C64 through to 32 ROM images in a 27C040. When testing this, I was
using an EEPROM, a 29C040, unfortunately as will all these 'standards', the
pinout is slightly different to the 27C040, so I've had to make a small
modification to my test board. I will fit a jumper in future revisions. I've
also bolted this to a base without a lid, useful for testing as it still holds
in place.
This is how I've loaded my test ROM image, I've split the cartridges up by type,
although there is no need to do this. The settings show the mode selection and
then the ROM address.
This leads me to think it would be easier to come up with some sort of menu
driven system which writes out to an I/O latch to set these options then reset
the system. I suspect that will be the next stage of evolution.
In parallel with this, I am also working on the IEEE-488 interface side of
what may become 'the penultimate cartridge'. So far I have reverse engineered
the Stack IEEE-488 board and built a simplified replacement.
Currently I have a strange totem pole arrangement out of the back of the VIC20.
The simple DIP switch controlled ROM/RAM board is now used
as part of the VIC20 Diagnostic cart and loopback cable sets available
from my Tindie store, either as PCBs, kits of parts, or assembled and
tested sets.
Penultimate Update:
The production version of the Penultimate Cartridge is now available from The Future Was 8 bit
The products and services mentioned within are no longer available.
I'm currently working on a VIC20 cartridge with an assortment of features, and as that is progressing, I have made a few prototype boards testing different features. The first of these was a general proof of concept, to test the practicalities, and was a VIC20 ROM and RAM expansion.
This provided configurable RAM expansion, and a choice of ROM images. One of the things this could be used for was replicating the VIC20 Diagnostic cartridge. This was a ROM cartridge, but required additional RAM to operate. The original was supplied with a 4K ROM (mapped as Block 5, A000) and 3K RAM (6x2114 mapped as RAM1, RAM2 and RAM3), The notes say only 1K was fitted, but photos of one board shows 6 x 2114s, which would be 3K?
Building a replacement was fairly straightforward, it is mainly loopbacks on the joystick, cassette and user ports, and a link from the user port to the serial port. There was also a keyboard loopback connector, but I haven't built one of those yet (it passes the test without it).
I'll still leave the diagnostic ROM image on the ROM/RAM cartridge, but it wanted to make a standalone version as well. Looking at the photos of the original, it looks to be use the same board as the VIC20 'Super Expander' Cartridge.
I had a spare super expander board, this one caused a black screen when used, due to a faulty mask ROM. I had removed the ROM and replaced it with a socket and tested it just as a 3K RAM cartridge and it was working fine.
I needed to burn a replacement ROM. The original cartridges used 4K ROMs which are not pin compatible with standard 2732 4K EPROMs. I think it is possible to change the links on the board to use a 2732 EPROM, but that would involve cutting tracks and adding solder bridges.
Rather than that, I used a 2532 EPROM, which is pin compatible. These are quite old and most programmers don't support them. With a few pin changes, you can program them as 2732 EPROMs, which many programmers still support. To make the pin changes I used an adapter board from Dave Stevenson, which allowed the 2532 to be programmed with my EPROM programmer set to 2732.
The programmed chip could then be inserted directly into the Super Expander board, turning it into a Diagnostics Cartridge.
I had borrowed the case from this cartridge for the ROM and RAM expansion, so I needed another one. As part of a collection of other Commodore stuff, I had picked up a strange double stack made out of two Super Expanders wired together.
I was told this used to plug into a muti slot cartridge adapter (which I didn't get with it). I couldn't use it as is, and wasn't sure how it was mapped in memory, with no additional address decoding and only 6K of RAM?
I'll look into what exactly that does another time, but for the moment, I borrowed the bottom case and cleaned up the cut out section to end up with a trendy side window. Maybe I should add some LED lighting?
I then found I had chosen a different diagnostic cartridge ROM image to the one I had put in the ROM / RAM cartridge, I think this is an NTSC version, as like a lot of games, it appears off centre on the screen.
So I burned another 2532 with a ROM image from Zimmers labelled 324173-01.bin. This appears centrally on the display of a PAL system, and is labelled as VC-20 Diagnostic, rather than VIC-20 Diagnostic.
I've tried that on a selection of boards, and it's proven quite useful. This was a dead mark 1 VIC20, with a white screen.
The diagnostic showed up a ROM fault, although it's not clear which ROM it means.
When it runs successfully, it shows ROMCHECK FF, ROMCHECK E0 and ROMCHECK C0. Not sure what the FF test signifies (char ROM?), but the second one is normally E0, so does this mean the ROM at E000? This is the kernal ROM in EU12, and that is a common failure.
I replaced that and it's back in business.
Here I'm testing a board with a faulty IEC bus, good to know it agrees with me
This can be caused by the 6522, but it's usually down to the 7406 buffer.
A replacement 7406 and it's back up and running, so I put it all back in the case and retested.
The test loops around and keeps track of the time, I left this running for several hours with no problems.
That leaves me with two choices now for VIC20 diagnostics, the standalone cartridge, or the multi-purpose one.
I have some new cartridge boards on the way, one is a revised version of the ROM and RAM board above, which adds more RAM options (including the full 35K required for DOOM), and more ROMs, now supporting 4K, 8K or 16K ROMs. There are also cutouts for the supports in some VIC20 cartridge, so this will fit in without having to remove them.
The other is redesign of the Stack IEEE-488 cart I tested previously. I've reverse engineered the design and then simplified it (and reduced the chip count) by using 75160 and 75161 buffers. There is also 32K RAM under the ROM chip and provision for a diode in the IRQ line of the 6522 should that prove necessary for WDC chips.
The final aim is to combine both of these and a PET microSD into a single cartridge, 'the Penultimate Cartridge'. That's going to be quite a challenge, so I am testing out all the elements separately first.
Update:
Anders from Sweden has uploaded a video demonstrating VIC20 diagnostics using one of my VIC20 ROM/RAM Cartridges.