Saturday, 16 February 2019

VIC20 Dead Test+

Sometimes when I am asked to do a job, I get a little carried away and 'over deliver'. That may have happened this time.
I was asked if I could add a little memory tester to the VIC20 Penultimate+ Cartridge. Since The Future Was 8 bit took over production of these, many hundreds of them have been sold. With those, we've only had a couple of problems, which usually turn out to be the VIC20 itself being faulty, so it would be useful if there was a way of testing the host VIC20's RAM. There is a VIC20 diagnostics cartridge that was produced by Commodore back in the day, but that was only really usable with a set of loopback plugs. If you didn't have those, it would fail on the first pass and just sit there flashing the screen showing 'Serial bus BAD'.
Looking to the Commodore 64, there are two common diagnostic utilities, the C64 Diagnostics, which suffered the same issues as the VIC20 with the need for loopbacks, but did keep cycling even if a problem was found.
The other option for the Commodore 64 was the Dead Test. This would only test the system RAM, but would do that using as little system resources as possible, to cope with faulty RAM, ROM or character ROM etc. This made use of the Ultimax mode, which was designed for the Max machine which had no internal ROM, so everything had to run from the cartridge.
My plan was to aim for something more like the C64 Dead Test, as it would used to test systems that may well have faulty RAM or ROMs etc. so would need to use as little of those as possible to cope with then being faulty. To that end, I set about writing this in assembler, and tried to work without using any of the VIC20s RAM, relying only on the RAM within the Penultimate Cartridge, which would have been tested during production of the cartridge. That limited me to assembly language, with no subroutines, and no use of the shorter, faster zero page addressing modes (with a small caveat - more details at the end of the post when most people will have stopped reading).
I started with the same sort of layout I had used on the original Penultimate Cartridge menu, rewritten to account for the limitations outlined above. That seemed to be working, so time to add some tests. I started at the start of RAM. The first 1K is provided by two 2114 SRAM chips, this is shown as 'RAM 0'. There is then a 3K gap (which can be filled with expansion RAM from the cartridge port). I'm not testing that here, as that is not part of the VIC20.
The final 4K of block 0 is provided by eight 2114 SRAM chips on the original (2 pin power) VIC20. The later VIC20-CR uses two 6116 RAM chips. This is shown in four 1K chunks, RAM 4,5,6 and 7. RAM 4 is used as the screen RAM, so that is tested differently, each character on the screen is first backed up, then tested by writing and reading values as you would normally do, then returned to it's original value. You can follow the cursor as it runs over the screen, which is preserved during the process.
The last block of memory is the colour RAM. This is tested in a similar way, one character at a time. This block of memory is only 4 bits wide, a single 2114 RAM chip. The results of the other blocks have included eight green ticks for bits that have passed, or red crosses for bits that have failed. From that you should be able to narrow any failures down to a single chip on either type of machine.
On the colour RAM, the lower 4 bits are shown as dashes as they are not implemented in hardware. The chevron indicates the block currently being tested, four for each 1K of RAM, 256 bytes at a time (which is quite handy on an 8 bit system). The dots indicate blocks as yet untested. Here are some screenshots from real hardware with RAM faults (or chips missing to simulate these).
A fault in the right hand 6116 shows up as errors in blocks 6 and 7.
That's if the whole chip is bad, but it will also detect smaller errors, down to a single bit, here simulated by bending up the leg of D6, so bit 6 will fail over the enter range of that chip.
The other bits pass, as they are connected, but the results of bit 6 will be wrong so that bit fails and the whole chip is marked as fail.
A fault in the left hand 6116 would be in blocks 4 and 5, which includes the video RAM, so the display will not be readable - the VIC chip is limited to using RAM inside the VIC20 for screen and colour RAM. I would have liked to map those to external RAM to avoid using the internal RAM, but that's not possible. however, the errors show up in red if the colour RAM is working, so that should point the finger at that particular chip.
A fault with the colour RAM likewise makes it difficult to read the screen, but again with knowledge of what the screen should show, you can see where the fault lies.
That's all the RAM tested, but lets also test the ROM chips. The C64 Dead Test doesn't do that, but I think it would be useful thing to add, hence Dead Test+.
The character ROM, BASIC ROM and KERNAL ROM are all checksummed and compared against a list of known 16 bit checksums for the common VIC20 ROMs. The results are shown, alongside a short description. A test is done on power up to check certain bytes in the KERNAL ROM to see if it is NTSC, and the video mode set accordingly. The spelling of 'colour' is adjusted so that it is spelled incorrectly differently if an NTSC ROM is present.
When all tests have completed, the VIC will play a short sound through each of it's three voices, then it will loop around again. A counter at the bottom of the screen shows a cycle count so you can use this for soak testing.
The VIC chip can display characters using the character ROM, or a font held in RAM. This alternates each cycle, so that if the character ROM is faulty, you should see a valid display when it switches to the RAM font.
You can also see the faulty ROM highlighted in red even if the character ROM is completely bad.
The VIC20 Dead Test+ has now been added to the Utilities menu on the VIC20 Penultimate+ Cartridge, and should be present in all cartridges shipped from December 2018 onward.
Obviously, if the VIC20 is faulty, then it's quite likely you are not going to be able to navigate the menu system, so you can also run the VIC20 Dead Test+ by holding down the reset button on the VIC20 Penultimate+ Cartridge for more than ten seconds on power on - the reset button is the one on the right for those of you playing along at home.
This will bypass the menu and go straight into the Dead Test+ program.The get back to the normal menu, just press the reset button for less than ten seconds. The VIC20 Penultimate+ Cartridge is available now from The Future Was 8 bit. Use discount code WHONEEDSSPRITES as a reward for reading this far and not just looking at the pictures.

Ooh, have we got a video? 

Yes, we've got a video.


Small caveat about limiting use of zero page and stack memory.

The first 1K of Block 0 is the internal RAM of the VIC20, which we need to test. It is also the zero page (0x0000-0x00FF)  for which the 6502 processor has some shorter (and therefore faster) op codes, so I couldn't use those. It also contains the first page (0x0100-0x01FF) which is used for the stack, so I couldn't use the stack. That means no subroutines, JSR instructions usually take parameters off the stack, and push a return address there to go back to on an RTS instruction, so I was stuck with pretty linear code with no subroutines. That turned out to be less of an issue as there was enough space to 'unroll' all the code and simply repeat subroutines where they were required (using preprocessor directives to avoid actually creating multiple duplicates in the source code).
That was all working fine until I checked the VIC20 Kernal Source, the first thing it does is check for a cartridge being present. Unfortunately, to do that, it jumps to a subroutine a few bytes away to check and then jumps back, so this will need those few bytes of ROM to be working as well as some of the 1st page of RAM. Not ideal, but the best we can do without replacing the KERNAL ROM.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.

Saturday, 9 February 2019

USB Arcade Controllers

Last  year I built a Picade kit from Pimoroni, it's been great and has had a lot of use by me and my nephews.
The only thing I had an issue with was the buttons and they way they were mapped, the joystick is the cursor keys, which is fine. The keys on the side and enter and escape, which is also fine, but the buttons on the top and the two on the front are mapped as shift, control, alt, z, x, o, i and space, which didn't really make sense and confused a few emulators which used those keys for other things.
I missed the clicky sound of microswitched buttons, so decided to fit some to replace the original low profile switches. They are the same diameter as normal arcade switches, so it was a simple job to swap them over.
I ordered some standard microswitched arcade switches (from arcadeworlduk) and wired those up.
I had ordered a selection of colours, so I colour coded the wiring, with two wires for each switch rather than a common ground.
I also took the opportunity to solder in and heatshrink the wires on the power button as the crimp tags felt a little loose.
I arranged the new buttons to try to match the colours of other four and six button arrangements - the blue and purple are more distinct that they have come out in the photos.
It was all a bit of a tight fit, getting in those six buttons, and four black buttons around the base of the case, but it all fell into place in the end.
Since the button usage was now more consistent, I used the stickers supplied with the Picade kit to label up some of the buttons. Did I get it right, are there better arrangements?
With all of those wired up, it was time to plug them in. I think by adjusting the setup script on the Pi I should have been able to map these to different keys still using the Picade X Hat controller, but decided to go a different way. I have found in the past the best option with Retropie was to use a game controller with lots of buttons and dedicated start and select buttons.
This is the replacement board I designed, it is a USB game controller with inputs for a 4 way joystick and up to 8 buttons.
Each of the inputs has it's own ground connection along the bottom of the board, all are switched to ground, no multiplexing or keyboard matrix is used here.
The original joystick was microswitched, so I left that as is. It was on a connector with 5 pins on, so I fitted a matching 5 pin socket. The buttons are connected to eight 2 pin headers, each with it's own ground. It could have been wired with a single ground wire, but it's neater and easier to swap things around using a 2 pin cable for each button.
That mounted nicely on the side of the case. The power switch and power LED are left wired to the Picade controller as before. With that connected and RetroPie reconfigured, it seemed to work a lot better with two buttons on the controller dedicated to start and select (the two on the front) and the 6 action buttons as X Y A B, left shoulder and right shoulder..
The two buttons on the sides of the case were setup originally as Enter and Escape. This seemed sensible, so I left those plugged into the Picade X HAT controller.
I had thought I might need to add more buttons, so I also designed an extension board, which has 64 inputs to act as 64 keys on a USB keyboard. As before, these are all individual inputs switch to a common ground.
That would allow individual arcade buttons to press any key you want, such as keys for coin up, player selection, F1 or F12 for menus, any of the letter or number keys etc. You could wire up a joystick to WASD, or to 5678 for Spectrum fans or anything else you can think of.
These are plug in and go, just wire a switch between any of the ground pins and "A" and when you press the switch it will be like you pressed "A" on a normal USB keyboard. I can see this would also be useful for creating those massive controllers people have for flight simulators etc. or adding buttons for menus, changing games, coin up etc.
These boards are available from my Tindie Store, with or without the keyboard extension.
In the usual DIY kit form with the built, programmed and tested controller board, mounting pillars and a USB lead.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.

Sunday, 3 February 2019

8K or 16K ROM Cartridge PCBs for Commodore VIC20

Yellow is the new green.
At least as far as VIC20 Cartridge PCBs go. These are the new 8K or 16K ROM cartridges from The Future Was 8 bit.
There are instructions on the back, but I'll go through the options in a bit more detail. First a quick refresher on the VIC20 memory map. The 6502 can address 64K (without paging), and on the VIC20, this is split into eight blocks. four (and a half) of which are assigned to the cartridge port.

Block
Address Range
Use
0
0000 - 1FFF
Internal 5K RAM + Cartridge RAM1/RAM2/RAM3
1
2000 - 3FFF
Cartridge BLK1
2
4000 - 5FFF
Cartridge BLK2
3
6000 - 7FFF
Cartridge BLK3
4
8000 - 9FFF
Video / IO space
5
A000 - BFFF
Cartridge BLK5 (autostart)
6
C000 - DFFF
BASIC ROM
7
E000 - FFFF
KERNAL ROM

Block 0 contains the internal RAM, and can be expanded with an additional 3K from the cartridge port (although not with this cartridge). Block 4 is video RAM and I/O space, and blocks 6 and 7 contain the system ROMs. That leaves blocks 1,2,3 and 5 for ROM cartridges. Block 5 is special in that it is checked on system startup to see if it contains a bootable ROM, if it does, that will be started instead of the normal BASIC. These cartridge PCBs can be used to provide a single block (8K mode), or two blocks (16K mode). I did look at adding 4 block (32K mode), but as far as I know, Cheese and Onion is the only 32K cartridge out there, so you should just buy one of those instead.
The locations of the cartridge ROM in memory is selected by means of two four-way jumper blocks. A second set of jumpers also allow multiple images to be fitted into larger EPROMs, and selected via jumpers.
The selections are different depending on the size of the ROM image used.

8K Mode

When using an 8K (or smaller) ROM image, the 8K/16K jumper should be set to 8K. The right hand block jumpers are used to select the block the ROM image will be located at. In almost all cases, this will be block 5, but the options are there for the other 3. In 8K mode, the 74LS00 chip is not used, so does not need to be fitted. Cross jumpers like that need a link making between the centre pin and the selected block. The offcuts from the legs of the capacitors are ideal for this.
In 8K mode, ROM chips from 27C64 to 27C512 can be used to provide between one and eight 8K ROM images that can be selected via jumper, or hard wired. Settings for some common EPROM types are shown below.

A15
A14
A13
27C64
28C64
27C128
27C256
28C256
27C512
0V
0V
0V
-
-
-
-
-
ROM 1
0V
0V
5V
-
-
-
-
-
ROM 2
0V
5V
0V
-
ROM 1
-
-
ROM 1
ROM 3
0V
5V
5V
-
ROM 1
-
-
ROM 2
ROM 4
5V
0V
0V
-
-
-
ROM 1
-
ROM 5
5V
0V
5V
-
-
-
ROM 2
-
ROM 6
5V
5V
0V
ROM 1
ROM 1
ROM 1
ROM 3
ROM 3
ROM 7
5V
5V
5V
ROM 1
ROM 1
ROM 2
ROM 4
ROM 4
ROM 8

In most cases, the easiest option is to set all three to 5V and place the image in the top 8K of whichever ROM chip is being used.

16K mode

In 16K mode, the 74LS00 needs to be fitted (as does it's associated decoupling capacitor). The 8K/16K link is set to 16K mode, and two blocks need to be selected. The left hand block of jumpers selects the block for the lower 8K of the 16K ROM image. The right hand block selects the upper block. The upper block is normally 5, but the lower varies between software houses. This shows blocks 1 and 5 selected (this time using jumpers rather than wire links) and the 74LS00 fitted.
27C64 and 28C64B EPROMs are not supported in 16K mode, so one to four 16K images can be fitted in a 27C128 - 27C512 EPROM. The A13 link needs to be set to 16K now, and the other two are used to select the 16K ROM image within a larger EPROM.

A15
A14
A13
27C128
27C256
28C256
27C512
0V
0V
16K
-
-
-
ROM 1
0V
5V
16K
-
-
ROM 1
ROM 2
5V
0V
16K
-
ROM 1
-
ROM 3
5V
5V
16K
ROM 1
ROM 2
ROM 2
ROM 4

Here I've fitted jumpers, but wire links can be used as before.

Installation

The cartridge PCBs can be fitted directly into a VIC20, the notches on the top edge provide a sort of handle to help remove the cartridge. It goes without saying, but I'll say it anyway for legal reasons, don't install or remove this with the power on.
They can also be fitted into original cartridge cases (to replace faulty cartridge boards for example), or into new The Future Was 8 bit cartridge cases.
I also like to fit things like this to the lower half of the case only, so the jumpers can be changed without opening the lid.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.