Sunday, 24 July 2016

VIC20 Penultimate Cartridge Preorder

I'm pleased to announce the VIC20 Penultimate Cartridge I have been working on is now going into production by www.thefuturewas8bit.com. Like the nicely cased SD2IEC they produce, the VIC20 Penultimate Cartridge is also going to have a custom case.
Taking styling cues from both the VIC20 and later Commodore 64 cartridge designs, it's going to look fantastic. The label is only on the top half of the case, so you can read it when it is inserted, unlike the original VIC20 cartridges, where you have to remove them to read the title. And let's face it, when this is installed, you're never going to want to remove it.
The colour should be close to that of the brown VIC20 utility cartridges, the thinking being that although VIC20 cases vary from bleached retrobrite white through to smokers teeth yellow, the keyboards are all still brown.
This case has been designed to accept standard VIC20 boards, including my current Penultimate Cartridge boards.
There are two buttons on the new case, so a new space invader shaped board has been designed. Rather than the section sticking out of the top, there are wings on the side with buttons for 'menu' and 'reset' in the corners.
The firmware is now at revision 5.0a, and includes 43 ROM titles, selectable via keyboard or joystick.
Included on there are text adventure cartridges which used to need the user to type 'SYS 32592' to start them. This has been automated, so they will run automatically.
From this menu you can also set common RAM sizes to exit to BASIC, or load a file browser from disk, ideally suited to loading FB20-8K from an SD2IEC. Block 5 RAM is cleared whenever it is used, to avoid auto starting anything you had previously loaded into there.
There is also an advanced menu where you can select which blocks of RAM to populate to suit any programs with particular requirements from 0K through to 35K.
The VIC20 Penultimate Cartridge is available to pre-order now from www.thefuturewas8bit.com.

Thursday, 7 July 2016

VIC20 Internal SD2IEC

If you've got a VIC20 or a Commodore 64 and you want a simple disk drive replacement, the solution is fairly straight forward, you get an SD2IEC.
These are some very nicely packaged versions from The Future Was 8 bit, in a variety of shades to suit a range of Commodore machines.
These work well with the new VIC20 Penultimate Cartridge, which can automatically start the file browser from its menu.
During the development I have been borrowing a clear SD2IEC from my clear cased C64C.
And also a nice VIC20 coloured one on my main VIC20, made out of recycled VIC20 cases.
The VIC20 I was using for development wasn't one of my best. It arrived with one of those Commodore power supplies where the 5V was more like 7.5V, and many of the chips on the board had been fried. I had to replace most of the chips to get it running, but it's been a useful test machine since most of those chips were now socketed.
Something I've been meaning to do for a while was try out the idea of an internal SD2IEC, so I thought this would be a good candidate.
The internal SD2IEC boards (the SD2IEC Classic V1.0) are similar to those used inside the normal SD2IEC units, but without the buttons. There are additional contacts at the edge of the board to fit buttons and duplicates of the onboard LEDs.
The only pins needed for the IEC bus are 6 at one end, so I fitted a 6 pin 0.1" header, soldered to each side of the board. You could just solder the wires directly, but I thought this would be neater and would allow it to be removed easily if necessary.
There are various points at which the wires can be attached, I chose a set of vias just before the 6pin DIN socket. These were a bit tarnished, but with some desolder braid and extra flux they cleaned up nicely.
I've marked the connection points, these are relevant to this revision of the board, the VIC20-CR 250403 / 251040-01 Rev D. Always a good idea to check continuity to the socket to make sure you have the right pins.
I've tapped 5V and ground at nearby vias and attached five wires to these five vias.
On the end I've fitted a 6 pin connector suitable to fit the 6 pin header (Harwin M20), and plugged this into the SD2IEC board.
I was initially thinking of resting this between the DIN sockets and the VIC shielding, but in the end I've gone for attaching it to the lid of the VIC shield with foam pads. Making sure the contacts are clear of the metalwork.
Testing this, the lights flash reassuringly and the file browser appears. If I were planning to close the case up, I think I would look at changing the VIC20's power LED for a tricolour one, red for power on and then amber for disk access.
This one, however, runs mainly without a lid, with the prototype Penultimate Cartridge installed, so the onboard LEDs are fine. My bench is now a little tidier.

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

Saturday, 2 July 2016

PET Diagnostics

System like the VIC20 or Commodore 64 have cartridge slots, so can run diagnostic software from there. The PET does not, so this is my new 6502 diagnostics board, a board which fits in place of the 6502 CPU in systems such as the Commodore PET to run diagnostics checks on a non-functional PET.
It controls the system under test from the CPU socket in order to test RAM and ROM and other system functionality. This version has no external outputs (the 6 pin header is for programming), and instead uses the hosts video circuitry to report the results on screen.
The first application of this is on the Commodote PET, a fairly standard 6502 system with fixed areas of ROM and RAM (no paging is used until the 8296). This is running my PET diagnostics software which makes use of the PET screen and writes to its video RAM to generate a display.
Early Commodore PETs (the 2001, 2001N, 30xx and 9" versions of the 40xx) had no dedicated screen controller chip, and the video output was just whatever was written to the 1K of screen RAM. This leads to a common fault on these PETs of a screen full or random characters, which in many others systems would be a black screen error. These PETs will show this with no system RAM, system ROM and even with no CPU installed.
When the system is powered up with the 6502 diagnostics board in the CPU socket, it writes to the screen RAM and as long as that is working, a display is generated. Even if it is not working correctly, having known text written to the screen can often help diagnose what is wrong with the video circuits, in order to let you then get on with fixing the ROM or RAM or whatever else is wrong.
There are three tests implemented on the main screen. The first is testing main RAM. The PETs have between 8K and 32K of RAM. This is tested in 8 blocks of 1K, 2K or 4K, depending on the amount of RAM selected. The results from each block show which bits were bad within that block, and how many errors in total were detected. On early systems with 6550 or 2114 static RAM, each chip handles a 4 bit wide 1K block, so one bad RAM chip would show up as bits 7654 or 3210 faulty (or parts within).
Later systems used 4116 DRAMs, each a 1 bit wide 16K block. One of these being faulty will show up as errors on that bit over all the sections it covers. I may look at tying these up to IC numbers in a future version of the software. The counts shown are all hexadecimal, so 1000 errors is actually 0x1000 errors, or 4096 errors, or basically the whole 4K block.
The next test actually happened first, before drawing the screen, the video RAM was tested (since testing the video RAM writes the test characters all over the screen). The results are shown as one or two 1K block, for 40 or 80 column PETs. Errors again shown by bit. Here some partly faulty video RAM can also been seen in the occasional invalid character being displayed.
The third test on this page is ROM 7 blocks or 2K or 4K depending on the system. The test is based on a 16 bit CRC of the ROM. I test this multiple times and if the result is consistent, I use a lookup table to show which chip this is. If the CRC is not consistent, this points to a fault chip. There are weak pullups on the databus, so empty sockets give all 0xFF bytes and a consistent CRC.
The 8032 I was testing here had a faulty kernal ROM, which showed gave an inconsistent CRC. So I was able to go straight to that chip, desolder it and replace it with an EPROM and the machine was back in running order.
When there are multiple ROM or RAM errors, it could be data or address buffers or address decoding, or it could just be multiple failures. 4116 DRAM chips don't last well if one of the three supply rails they need fail. If you have multiple failures, it it sometimes a cheaper option to go for a ROM/RAM replacement board, rather than replacing lots of chips. It can also be used to add more RAM or upgrade the version of BASIC.
The socket numbers are displayed next to the ROM results. I have actually had several PET boards in for repair which had all the right chips, but in the wrong socket. All being well, all those test pass and it holds on that screen for 10 seconds to check the results.
It then clears the screen and shows a character map. After a few seconds, the character set is changed and the alternate graphics / business characters can be seen. The PET has two character sets controlled by an IO pin setting an address line on the character ROM, so only one can be displayed at a time.
The original PET 2001 always had upper case characters in the range 00-1F region, and alternated graphics or lower case in the 40-5F range. Later PETs decided to confuse things and have upper case at 00-1F and graphics at 40-5F in graphics mode, but to switch things around and have lower case 00-1F and upper case 40-5F, which is why you occasionally get some software with annoying rEVERSE cAPITALISATION or symbols where the upper case characters should be like \aze or |litz.
After the two character maps, it goes back around and repeats all the tests, so you can just leave this running and check back to see if there are any changes to the ROM and RAM tests once the system warms up.
There are different amounts of ROM and RAM in PET systems, as well as other changes, such as the reversed character sets on the original 2001, and the CRTC initialisation on 12" 4032 and 8032 machines. Rater than having different builds for each machine, I have used a set of DIP switches to select the machine.
Sw1
Sw2
Sw3
Machine
ROM
RAM
Video
0
0
0
12" 4032
6x4K + 2K
32K
CRTC 40 col 50Hz
0
0
1
12" 4032
6x4K + 2K
32K
CRTC 40 col 60Hz
0
1
0
8032
6x4K + 2K
32K
CRTC 80 col 50Hz
0
1
1
8032
6x4K + 2K
32K
CRTC 80 col 60Hz
1
0
0
2001
7 x 2K
8K
no CRTC 40 col
1
0
1
2001N-8/3008/4008
6x4K + 2K
8K
no CRTC 40 col
1
1
0
2001N-16/3016/4016
6x4K + 2K
16K
no CRTC 40 col
1
1
1
2001N-32/3032/4032
6x4K + 2K
32K
no CRTC 40 col

If the machines is one of the 12" 4032 or 8032 systems with a CRTC chip controlling the video, this needs to be correctly initialised before the screen will show anything, so that is the default setting. Most of these are 40 column systems, the 80 column version just uses the left hand side of the screen, other than the border and title.
Using the PET diagnostics is just a case of removing the 6502 CPU, installing the 6502 diagnostics board in it's place and switching on. There is no 6502 processor in this system. The only code running is on the microcontroller on the 6502 diagnostics board.
I have various plans for this, I will be adding a second screen of tests for the VIA and PIA chips and the IEEE-488 port and any other things I can think of testing. I am also looking at adding a serial output to give the results on systems with faulty displays, but the real answer is fix the display first, then you can get on with testing the rest.

If you would like one of these 6502 diagnostics boards with PET diagnostics software, you can order one below.

PET Diagnostics

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

Saturday, 18 June 2016

VIC20 Penultimate Cartridge Part 4

This is the new version of the VIC20 Penultimate Cartridge, and you may notice something different. No more DIP switches. This one is menu driven.
I've been building a variety of cartridges for the VIC20 recently, from simple cartridge replacements to large ROM/RAM boards. This cartridge I had named 'The Penultimate Cartridge' as there seemed to be lots of revisions of Ultimate and Final Cartridges for this and other systems, so I thought I would be honest.
This had up to 35K of RAM (3K + 8K + 8K + 8K + 8K) and 32 ROM images (4K/8K/16K). These were selected by DIP switch. But that wasn't ideal, as they can be a bit fiddly for regular use, and you keep needing to refer to the list of settings. It would be nice if there was a way to set the choice without using the DIP switches, a menu system of some kind.
My initial thoughts were to use a couple of 8 bit latches to form simple output ports. These would be set by the menu software to change the switch settings, but that was going to get complicated. I did think about using something like a 6520 or 6522 which are dual 8 bit ports (and more), but they are quite large.
Instead, I went for a microcontroller. In the prototype, I chose an Atmel ATmega328P (as used in the Arduino Uno), although I am using the ATmega48PA in the actual cartridges. This is wired 'dead bug' style onto one of the previous cartridges. I built up a board without DIP switches and installed some LEDs for testing. Don't worry, this isn't the final version either (see, why it's Penultimate).
The microcontroller is there for a couple of reasons, it could be the pair of latches, with enough inputs and outputs to replace the DIP switches. I used the final address line available on the 32 pin ROM socket, so I could go up to a 27C080 EPROM with 64 ROM images, although I'm sticking with 32 at the moment. I also wanted to be able to preset an option for these and I needed it to be able to reset the VIC20 to read in the new cartridges.
What was a reset button on the original became a menu button. Pressing this puts the VIC20 into reset, switches the mode and the ROM address to select a menu program in ROM and then takes the VIC20 out of reset to boot up the menu ROM.
The menu program would then allow the user to select their option and would change the switch settings appropriately. This would be poking a number to an IO address mapped to the cartridge slot (I used 0x98xx). When this happened, there is a short pulse on the relevant enable line. It wasn't initially working, so time for the logic analyser again.
Even running at 16MHz the microcontroller didn't respond fast enough to that on an interrupt pin, so I had to change it to poll that pin in a loop. It hasn't got anything better to do, so it just sits there polling the input pin. Now it was time to write the menu program.
This was my first attempt, written in BASIC and loaded from disk. This proved the principle, it worked. Now I just needed to get that working as a cartridge. It's been a while since I wrote code for a 6502 system. I wrote loads for the BBC micro back in the day, but not much recently. There was little information on the necessary magic to convert some C or assembler into a cartridge, but I was pointed at some sample code (thanks to Stefan Vogt).
I though, oh, that's nice, there's some double width fonts in there for the titles. Then I remembered I was on a VIC20, and that was the normal font. It took a while to be able to build that as the code was lacking any information on the settings required to build it, and there were errors in some of the files. But it was the information I needed and I got it working and I was away. As someone who writes a lot of code, you get used to certain development environments. I was testing out cartridge code initially with notepad++ text editor and cc65 on the command line. I was pointed at the Atom IDE, but it didn't work for me, so I went back to Microsoft Visual Studio.
I set this up as a makefile project, but without a makefile, and just a command line to compile all the .c files in the project. That worked nicely and I could just type away with nice syntax highlighting, my usual source control (SVN) and all the tools of my usual IDE.
The main menu turned out to be fairly simple to do, just build up a list of the cartridges on the ROM, and which mode and address they need and present the menu to the user. I tried to make this as simple to use as I could and went for numbered entries, a page at a time, rather than scrolling down through a long list.
This is an early version of the menu. Red is always a difficult colour on a PAL system, and it didn't come out well, so I changed it to yellow later on. There were three elements to this, a list of ROM cartridges that could be started immediately as if the real cartridge was plugged in, a list of memory options to act as a RAM expansion, and the option to boot straight to a filebrowser or the default program on a disk.
I added an 'Advanced' menu with just RAM options, to give all the combinations of RAM available from unexpanded, up to 'all banks' which gives a total of 35K additional RAM. The cartridge and the RAM were easy, as these were just a case of poking the mode and address to the cartridge. I wanted to include some of the Scott Adams text adventures (OK, well all of them), on there, and these have an odd quirk in that they do not automatically start. The cartridge case reminds you that you need to type SYS 32592 to start the adventure. This isn't ideal, I'd like to make those automatically start. How hard can it be?
Well, quite difficult it turned out. The cartridge uses two 8K block, but neither in block 5, so it doesn't auto start. Apparently it was so full of code there wan't space for the loader code. What I was thinking was just setup the ROMs and then jump to address 32592. That doesn't work for two reasons. One, as soon as the cartridge ROM settings are changed to page in the game ROM, the currently running code which was about to run JMP 32592 is no longer there. To get around that I had to jump through quite a few hoops. It was a very interesting process picking apart the VIC20 memory map and kernal ROM disassembly to see how it all worked. I needed to create a small chunk of code which would switch the mode and then run the game. This needed to be copied to somewhere in memory where it wouldn't be affected when the cartridge mode was changed. I identified the cassette buffer would be suitable. This is 192 bytes at 0x0340 - 0x03FF.
I wrote the code, in 6502 assembler, that would do the switch and the code to copy it to the cassette buffer and run it, but it didn't work. This was the second reason, it appears it needs quite a bit of the BASIC initialisation to happen before it will run. A bit more reverse engineering later, and I had it running bits of the kernal initialisation code and then jumping to the ROM. This also hit problems, as BASIC initialisation very thoughtfully cleared the cassette buffer, and obliterated the code that was running. The second time this code has had the bits pulled out from under it's feet. To get around that, I wrote a modified version of the BASIC initialisation which didn't clear the cassette buffer and finally that worked. You can now select one of those and it will automatically start. A lot more effort that just typing 'SYS 32592' every now and then, but I like an interesting challenge.
The next challenge was to automatically load and run a program from disk. How hard can that be? Yes, you guessed it, quite tricky as well. I was thinking this would be a good companion to an SD2IEC disk drive replacement, being able to automatically start it's file browser.
To do that, I had to change the memory mode of the cartridge, and again, the running code disappears. The same solution worked out here, create some code to do the memory mode change, load and run the program, and run it from the cassette buffer. Again duplicating the BASIC initialisation code, a bit further this time, and again writing in assembler. It all came back to me thirty years later, and by the end of this I was hand assembling it to create the array of bytes in the final code.
It took quite a while to work out what combination of calls kernal code were required to setup and load a file, reparse and finally execute it, but I was rather pleased when my test program was finally loaded from disk and run automatically from the cartridge menu program.
Due to the convoluted nature of the memory MAP on the VIC20, there are several versions of the file browser, so I choose the appropriate one to run based on the amount of memory selected. Yes, there is the FB program which will detect the amount of RAM and run the right program, but why add the extra step.
With that coding finished, it's now feature complete. At the last minute, I've added in drive number selection, press D to cycle through 8-9-10-11 and back to 8.
So there it is the finished VIC20 Penultimate Cartridge. There are a few things I might add to it, such as joystick support, and maybe an integrated file browser, but that's it for the moment. I've been testing this on a standard PAL VIC20-CR. This will probably not work if you have any internal RAM upgrades already fitted to your VIC20. I am awaiting results of testing on an NTSC VIC20. Update: It works fine with Jiffy DOS kernal, which is noticeably faster accessing the SD2IEC. Testing with the VIC20 port of Doom as that uses all 35K of RAM. Normal Kernal: 10 seconds to load file browser, 60 seconds to load Doom. Jiffy DOS: 2 seconds to load file browser, 11 seconds to load Doom.
I've made the PCB in the same format as the previous ones, so that it will fit into an existing cartridge case. Here I've used a dead Comic Cruncher cartridge that looks to have been left out in the rain or something. All corroded and a peeling label.
I removed the label and the corroded PCB and stuck on a label sent to me by Mike Robertson, who made it for his Penultimate Cartridge.
This goes well with one of the nice SD2IECs from thefuturewas8bit.com, here is my modified cartridge next to a VIC20 coloured SD2IEC.
This all fits together nicely with the VIC20 to give you access to 31 39 ROM cartridges directly, or as many carts and D64 images as you can fit on the SD card int the SD2IEC (which is all of them, many times over).
You can buy one of these VIC20 Penultimate Cartridge boards now, programmed and tested. You can use it as a bare board or fit in a spare cartridge case.

VIC20 Penultimate Cartridge V4.3
UPDATE 1:
I've managed to squeeze more cartridge images into the ROM by doubling up the 8K cartridges. I had considered this with the DIP switch version, but didn't have enough switches. Now it's under software control, I can fit two 8K images into each 16K bank and address them separately, so there could be up to 62 8K carts on the standard, or 31 16K carts, or a combination of both. There are now 37 cartridges on the menu, and space for a few more.

UPDATE 2:
I've added support for joystick navigation to the menu. Up and down moves within the displayed page. Left and right change page. You can also scroll down onto the next page. Fire loads the ROM.
I've also added some disk commands before loading the SD2IED file browser. It will now change out of a disk image (if one is loaded) and back to the root, where the file browser lives.
A few cartridges have been added, taking the total to 39. There is still a bit of space free for a few more.

UPDATE 3:
The firmware has been updated to v5.0a, with the total up to 43 ROMs. The uncased versions are still available above. The custom cased versions are now available to preorder now from www.thefuturewas8bit.com.

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