Sunday, 22 December 2024

Reading the joystick port from VIC20 BASIC

The post I wrote on fixing Autofire in VIC20 Bandits (and Multitron) was originally much longer. Patreon supporters got to see the full version in October, but when I came to post it here on the blog in November, I thought it was too long, so I cut some bits out. I now present the "deleted and extended scenes" from that post.

Let's start with a bit of VIC20 BASIC.

Reading a joystick on a VIC20 from BASIC

To read port A of first 6522 VIA chip in the VIC20, you can use the BASIC command

    PRINT PEEK(37137)

You can write a very simple program to repeatedly print that out

    10 PRINT PEEK(37137)

    20 GOTO 10

If you take a standard VIC20 with nothing attached and do that you will get a value of 126 all the time.

If you have a joystick plugged in, you will still read 126.

If you press fire, the value will change to 94.

If you move up, the value will change to 122.

If you move down, the value will change to 118.

If you move left, the value will change to 110.

If you move right, the value will still read 126.

That's a bit of an unfortunate quirk of the VIC20. For some inexplicable reason, the joystick right input is on a different port, on a different chip, so you have to do

    PRINT PEEK(37152)

Normally that will read 247.

If you move right, the value will still read 247.

But I thought you said....

Yeah, another quirk of the VIC20. That port is normally all outputs, driving the keyboard columns. In order to read it, you have to set it to an input first.

Really? but that's very inconvenient. Yeah, well, I didn't design it.

Instead you need to do something like this

    10 POKE 37154, 127 : PRINT PEEK(37152) : POKE 37154, 255

    20 GOTO 10

That will set the relevant pin to an input, read the value, then set it back to an output so it will not mess up the keyboard scan routine.

Now if you run that it will normally print 247.

If you move right, the value will change to 119.

(although ideally you would not have the PRINT routine there, just read to a value to reduce the time where the pin is not an output)

Given that information, you could write a simple program that reads those ports, and compares against those values.

    IF PEEK(37137) = 94 THEN PRINT "fire!"

However, there are a few problem. If you move up and press fire at the same time, you get a different value, 90, so the test would fail.

A better way is to test the individual bits, so

    IF (32 AND PEEK(37137))=0 THEN PRINT "fire!"

(it is never ideal doing bitwise work in decimal, it is much easier to see in hex or binary, but that's what we're stuck with in BASIC).

10 A = PEEK (37151)

20 POKE 37154,127 : B = PEEK (37152) : POKE 37154,255

30 IF (A AND 4) = 0 THEN PRINT "up"

40 IF (A AND 8) = 0 THEN PRINT "down"

50 IF (A AND 16) = 0 THEN PRINT "left"

60 IF (B AND 128) = 0 THEN PRINT "right"

70 IF (A AND 32) = 0 THEN PRINT "fire"

80 GOTO 10

That seems to work.

But what about the other bits?

There are also some other issues with just comparing values.

If you have a datasette plugged in, the value of 37137 will still read 126.

If you have left the play key pressed after loading, the value will now read 62.

All your comparisons by value will now be broken, bitwise tests will be fine.

The obviously causes an issue for some games, which have a "PLEASE STOP TAPE" message at the start of the game (rather than changing the tests to cope with that)

Something else that affects the value is the IEC bus.

If you have a IEC drive plugged in, the value of 37137 will still read 126 at power on.

If you have accessed that drive, it will now read 127.

Any developers working on a purely tape based system may not have known that.

There was also this long section that was cut where I worked through what was happening in the game Bandits.

There is one more game on the cartridge which has this autofire issue, but I haven't been able to fix that before. Time to have another go.

Fixing Bandits

I wonder if I can fix Bandits now? That seems to just autofire all the time, it does move correctly, but fire is stuck on.

The issue is the same, although the implementation is a lot more complicated.

   lda $9111

   asl

   asl

   asl

   bcs label_b410

   and #$ef

And it goes on

label_b410

   asl $9120

   ror

   ora #$04

OK, I worked through this to find out what is going on. The ASL is arithmetic shift left. That moves the state of the fire button out into the carry. That gets rid of the IEC ATN and cassette sense in the process, but leave the IEC clock and data in the mix (now moved to bits 3 and 4)

It can test the fire status by checking the carry bit. If it is clear (i.e. if fire button pressed), it clears a different bit with an AND instruction. It clears bit 4, and in future testing, that is the bit it now uses for testing fire. (why it does this I don't know, maybe they just wanted the directions together?)

After that it reads VIA#2 Port B and shifts bit 7 of that into carry. The ROR is rotate right, that rolls the carry (joystick right) into the accumulator.

Finally it ORs this with 04, which forces bit 2 high.

The final upshot of all that is the accumulator now contains joystick right, joystick left, joystick down, joystick up, and the reposition joystick fire. It then saves this and uses it for comparisons.

        C 7 6 5 4 3 2 1 0

Read   x A C F L D U d c

         ASL    A C F L D U d c 0

         ASL    C F L D U d c 0 0

         ASL    F L D U d c 0 0 0

         AND EF F L D U f c 0 0 0   if fire f = 0, otherwise d       

       ASL 9120 R L D U f c 0 0 0

         ROR    0 R L D U f c 0 0

         ORA 04 0 R L D U f 1 0 0

On a normal VIC20 with no IEC device attached, that works fine. It assumes that the value of bit 4 part way through shuffling is going to be a 1. It then sets it to 0 if fire is pressed. However, if the value of that pin is already 0, then it will think fire is pressed when it isn't.

That bit happens to contain the value read from the IEC data pin, the top trace in yellow as before.

That is how it looks if you have no IEC device connected. The dips are when the chip is in reset. The drive pins become inputs, and the inputs to the 7406 buffers float high and assert the signals. After reset, the pins are set as outputs. Data and ATN are released, but clock stays asserted as that is the default state for the VIC20. Basically it is putting it's towel down on the deckchair and saying "if anyone is going to talk around here, it is going to be me".

If there is an IEC device present, it sees that and responds appropriately by asserting data to say it is ready to receive.

Bandits seems to interpret that as fire being pressed.

The autofire can score quite well just sitting there, but ideally you would have control.

As with the other games you can avoid this by not having an IEC device attached.

The odd thing with Bandits, is you can also"fix" the problem by pressing the drive reset button. That's unusual, I don't think any of the other games were helped by this.

I tried all sorts of things, including resetting the drive via software before launching the game, but always when it started it would it would end up with the data line held low.

I finally got to the bottom of why, and it wasn't part of the code above that reads the port, it was earlier on in the initialisation........

The story continues in the main post where I then went on to fix the problems in Multitron and Bandits.

Advertisements

The patched versions of Bandits and Multitron are included in the new Penultimate +3 version which also has a built in SD2IEC drive.

Minstrel 2 and 3 kits and PET repair parts are available from my Tindie store..

I will slowly be moving things over there from my SellMyRetro store, so if there is anything that you want, let me know and I'll add it.


Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. This also includes access to my Patreon only Discord server for even more regular updates.

Posted by at
Labels: ,

Sunday, 15 December 2024

VIC20 / VIC-1001 Video output

The eagle eyed amongst you may have noticed a bodge board near the VIC chip on the early VIC-20 board I repaired in the last post (http://blog.tynemouthsoftware.co.uk/2024/12/vic20-vic-1001-repair.html)

This is presumably a factory modification, the board has a Commodore part number (321461)

But what does it do?

Well, as I have been working on the Mini VIC, I have reached the conclusion that the video output on the VIC20 is a bit like the switching regulator in the ZX Spectrum. It changes with every revision of the board, sometimes mid revision with factory mods applied to production units, and it is still rubbish even after all of that, they never did get it right.

As far as I know all the VIC chips are essentially the same. However the outputs vary quite a bit from chip to chip, even in the same batch. Maybe in an attempt to deal with this the VIC20 video output circuitry changed significantly over time.

6560-101 is the NTSC VIC chip and 6561-101 is for PAL (other suffixes are for different variants of the optional pins as described in the 6560 datasheet - I don't think I have ever seen one that isn't the standard -101 version, other than a 6561E in one of the later photos which is also the same).

This appears to be the third version. The first was on the actual Japanese VIC-1001.

VIC-1001

Pictures of the early boards are taken from the excellent Commodore VIC 20: A Visual History by Giacomo M. Vernoni (used with permission)

This is presumably the very first revision. 1980 date code. There are more board revisions than their are schematics online for the VIC20, and some of the boards don't match the schematics anyway, so I have reverse engineered these to see what is going on.

Notice the track break under the 47Ω resistor? And two vertical resistors to the sides of the capacitor in the middle that are using the pads of a single horizontal resistor.

This is the published version of the VIC-1001 schematic, drawn in a different style to all the later VIC20 schematics.

This is my best guess at what is actually going on. The 75Ω resistor R30 does not seem to be present and there is an extra 470Ω resistor that I am not sure what that is doing. But it does include the two biasing resistors that were fitted vertically in that place of what looks to have been a single pullup resistor.

The circuitry here has to do a few things. The video output of the VIC chip is in two parts. One pin outputs sync and luminance signals, basically black and white composite video as would be generated by a ZX81 or Mini PET etc. It is difficult to get a clean version of that as it picks up interference from the chrominance even when disconnected.

The second signal, the bottom trace, is that chrominance signal, high frequency colour information.

The VIC is internally S-Video, although that standard did not exist when the VIC20 was born. Normally the two signals are combined almost immediately they leave the chip.

It is possible to get an S-Video output from a VIC 20. It is a simple mod, but is only worth doing if you have a good S-Video monitor or capture gear. I have seen quite a few things which claim to have S-Video input, but all the do is merge the signals to get composite and display that. I have been meaning to convert one for a while, but I don't have a good S-Video display in my normal setup.

To generate composite video, these need to be combined.

To complicate things, the levels need to be adjusted here and there to get the combined signal at the correct level to drive a monitor input. (since those levels change from VIC chip to VIC chip)

A further complication is the sync and luminance output is open collector. Meaning it drives to ground only, so needs a pullup resistor to bring it up to the correct level.

This version combines the two signals directly with a 100pF capacitor (at least according to the schematic, although that also shows a 220pF capacitor to ground which does not appear to be present on this board revision).

The pullup is controlled by the variable resistor, giving a range of 0-5V for the pullup.

That would be adjusted to get the 1V peak-peak video signal on pin 4 of the AV connector.

On these early boards, there was also a second video output, higher voltage, on pin 5.

The combined and pulled up signal is then decoupled by a 22µF capacitor and biased by a pair of resistors. These are mounted vertically, so I can't see the values. I will assume they are as per the schematic and later board revisions, 3.9KΩ and 8.2kΩ. This is buffered by a simple emitter follower transistor amplifier and output across the two output resistors.(Update, the schematic shows 6.2kΩ rather than 8.2kΩ, but that may be a typo since 62 is not a standard E12 value, but 82 is.)

The audio is buffered by another simple emitter follower and fed to the AV jack (pin 3).

The VIC20 does not have an onboard RF modulator, it came with a one in an external box which plugged into the 5 pin AV jack. Power for that is provided on pin 1. On this board, that is derived from the 9V supply, via a 180Ω resistor and marked as "6V".

Later VICs changed almost all of that.

First NTSC VIC20

The next revision is the first official VIC 20, the board which looked very much like the VIC-1001, but with a few minor changes.

Again, I have reverse engineered that as best as I can as I have not seen a schematic that matches it.

This has two jumper pads in place of the drilled out trace. The 470Ω resistor is gone, and the 220pF that was on the VIC-1001 schematic has reappeared. There is a new 75Ω resistor added between the level adjustment potentiometer and composite video signal.

The "6V" has been replaced by a direct connection to 5V, see the wire link to the right of the VIC chip. All future VICs just had 5V direct like this. Even though the manual continued to say 6V I think all of the production VIC20 boards were 5V.

Second NTSC VIC20

That is the version of PCB that is used on the VIC20 board I repaired, but it had various modifications.

It just about matches this photo from the book, so I presume this became a standard modification, although the one I worked on had no silk screen.

Some parts have been removed, some bypassed, and the extra board added with a transistor and some passive components.

I presumed this must be additional buffering or an amplification stage, but both were wrong.

The new board is actually working as a voltage regulator. The potentiometer now feeds the mod board and creates a regulated and smoothed supply to pullup the sync and luma output.

The 220pF capacitor to ground is gone again, and so is the decoupling capacitor and biasing resistors, so the output is just an emitter follower to buffer the signal.

I guess this smoothed supply was an attempt to reduce noise, and I have to say this was one of the nicest pictures I have seen from an NTSC VIC, with a clean straight line between the border and background, rather than the usual ripply line.

This one does not suffer from the usual mushy colours around the white lines either, nice and crisp, and strong colours as well.

It is also the first one that seems to have the levels right on the output.

NTSC 2 pin VIC20

Things seemed to change radically for the NTSC 2 pin VIC20 with all the mods for FCC approval.

There were a few variations. This one has a different version of the voltage regulator mod board above integrated into the design. The capacitor is now on the input rather than the output. Not sure I agree with that, maybe a small capacitor on the input as that should be stable, and the larger one on the output? Even a zener on the input to fix the voltage?

Over versions removed that regulator altogether and just used a simple pullup resistor.

Most of these had two potentiometers, one to set the signal level buy adjusting a tap on the input signal rather than adjusting the pullup level. The second pot sets the black level.

The two output signals are generated differently, now using an LC network instead of a potential divider.

(also note the PN2222, the favourite transistor of Commodore at the time, used everywhere. The VIC-1001 used three different transistors types)

PAL 2 pin VIC20


The first PAL version had more changes (and the extra clock divider on the right). Some values changed and parts were omitted, including the can itself.

VIC20 CR

And things changed again for the cost reduced VIC20-CR board.

This was the simplest (and I think worst) version.

Just a simple pullup resistor on the output. Then the level setting pot. Decoupled and biased and then the emitter follower output to both pins tied together on the output. No more high and low variants.

I am not sure if it was just a PAL change, or if later NTSC boards were the same, but most of the VIC20-CR boards I have seen have the capacitor that adds the chrominance to the luminance at 45° on the board, actually connected to the output of the level setting potentiometer rather than it's input. Which is why most PAL VIC20-CR boards you will see have far too much chrominance, overloading the luminance signal.

I have not seen a version of the schematic with this mod, so I made one.

Update

It appears the 321461 Mod Board was available in kit form, presumably to service centers. Pictures of this board and scans thanks to Commodore Z.

Looks to be the same board that was fitted to the VIC20 I repaired.

There are fitting instructions included.

There are even schematics, I think my reverse engineered version was correct, but it is nice to see the proper version.

Advertisements

Minstrel 2 and 3 kits and many of my PET repair and upgrade products are available from my Tindie store.

I will slowly be moving things over there from my SellMyRetro store, so if there is anything that you want, let me know and I'll add it.

More info can be found here:

Bluesky

For those interested in such things, I can now be found on Bluesky, and I expect to be posting more there.

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates.

I am currently working on the Mini VIC, a VIC 20 replacement board or standalone computer kit. You can follow along with the development of that with many posts on Patreon already. Also includes access to my Patreon only Discord server for even more regular updates.

Posted by at
Labels: ,

Sunday, 8 December 2024

VIC20 / VIC-1001 Repair

I had a request for help with a broken VIC20 from a friend in America. Seemed like a normal faulty VIC20 until he sent me a photo of the board.

Well now, that's not your average VIC20. That's a very early one with the same board* as the VIC-1001, the original Japanese version.

* well, almost the same, see next week's post for more information on the differences

Compare that to the usual 2 pin VIC20 board and you will see it is very different.

I like the VIC-1001 layout better, it seems a lot cleaner. I Presume the board was reworked by Commodore USA for FCC compliance reasons, see all the filtering added to the power input on the right, and the tin can for the VIC and the clock circuitry.

All the interesting stuff seems to be on the left hand side of the board.

The layout of the CPU, ROMs and IO chips in a row is reminiscent of the C64.

The right hand side is just the cartridge and side connectors, and the massive heatsinks for the 5V regulator and bridge rectifier. (the board uses about 1.5A in normal operation so it does get a bit warm).

The back of the board on the left is just as sparse, lovely track work though.

It is almost as if it was originally only going to be half as wide, maybe with the cartridge slot rotated 90 degrees and joystick port on the side. Not quite small enough for this mockup photo with a PET chicklet keyboard, but not far off.

This one was inside a normal breadbin case. An early one with a silver VIC20 label and a keyboard with PET style keycaps.

VIC20s of this era had a dangerously misleading sticker on the bottom.

Seems to imply it takes 117V AC directly in the side, not 9V AC via the AC transformer. Made worse by the 2 pin power connector being similar to that used for electric shavers at the time.

I hope no VIC20s got fried due to that.

The US 2 pin connector is different to that used on UK 2 pin VIC20s (even though both are 9VAC). I don't have one of those, so crocodile clips to the rescue.

Time to power it up.

What's wrong with it?

Well, it is showing a screen full of garbage characters and colours.

OK, not a bad start. The VIC chip is probably working, as is the 6502 and some of the RAM and ROM.

It is not like a PET where you will still get a screen of garbage if you remove all the system ROM and RAM and even the CPU.

Here it has got as far as initialising the VIC chip, but not as far as clearing the screen or putting up a READY prompt. Could be a bad BASIC ROM?

I am told the VIC has already been replaced, and probably several of the other chips as they are all showing 1982 date code, whereas the rest of the board (and the KERNAL ROM) are showing 1981. Matching the nice "Produced 7/81 sticker" on the heatsink.

The KERNAL ROM and several of the other 1981 chips have an unusual sticker on them.

I am told "保" means "Save" or "Protect". Not sure what that means in this context. The KERNAL ROM chip contents is binary identical to the normal NTSC VIC 20 KERNAL ROM.

I did try them out of a good VIC20 board, and they were all fine.

Time to get the Penultimate Cartridge out and fire up Dead Test.

If you hold down the reset button (on the right of the cartridge) at power on, it will jump straight into Dead Test. The design of the VIC20 means that the KERNAL ROM and the RAM at $0100-$01FF need to be at least partially working. If it does not start, check those.

It did start, so that's a good sign, and the ROMs all pass.

However, it seems to consistently show RAM faults in RAM 5, 6 and 7. It seems unlikely that all of that RAM would be bad, something like that would normally be an issue with address decoding / chip select lines, with those chips not being enabled when they should be, or something else being enabled at the same time and causing bus conflicts. The 74LS133 and particularly the 74LS138s are good at failing and causing that.

The bad section covers $1400 - $1FFF, six out of the ten 2114 RAM chips (eleven if you count the colour RAM).

That is the top six here. They do look a little crusty. Not sure what's happened there.

Oooh, nasty. Never seen a head gasket failure on a RAM chip before. These are Mitsubishi chips. I could understand if they were made by Rover ......

It is just as nasty on the scope.

It is never good to see signals that are not high or low, but somewhere in between.

This board follows a grid layout, like the PET and many others of the era.

Letters go across the board, numbers up the side. You can see some of them circled above. The RAM chips are UA2, UA3, up to UA6 and UB2 to UB6. The colour RAM is on it's own over at UD3, and there is a clear gap at UC5. I wonder if there was originally another 245 buffer in that location?

When they moved to later boards, they kept those designations, even though they didn't use the grid any more. And when they added new chips, they numbered them.

The RAM on the VIC20-CR still has UD2 and UE2 and UE1, but the new 6116 2Kx8 RAM chips are U14 and U15 (as I am reading this back, I realise these designators refer to the grid on the normal 2 pin VIC20, but you get the idea anyway)

I have traced back those signals to the 74LS138 at UC1 and the 74LS245 at UD3.

UC1 is used to generate eight chip select lines for eight 1K blocks in bank 0. $0000-$03FF, $0400-$07FF etc. up to $1C00-$1FFF.

Five of these feed pairs of 1K x 4bit SRAM chips, giving the 5K of internal RAM. Three of them go to the cartridge connector where the 3K expansion can be fitted to fill the gap at $0400-$0FFF.

Several of those chip select lines were showing this intermediate logic state, so bad 138?

Well yes, possibly, but also the inputs were doing similarly odd things.

I replaced the 245 at UD3 and that fixed the signals going into the 74LS138, but there were still issues with the chip select lines coming out of the 74LS138.

I replaced that, and it fixed the signal coming out of the chip.

Great, sorted?

Well, no, there were still RAM faults. The same RAM faults.

Six bad RAM chips.

Six bad RAM chips? Surely not.

I decided I needed to be sure, so I moved the 74LS138 to a breadboard.

Most of the pins were wired straight through, but I moved the five chips select inputs and the five chip select outputs to the left hand side.

From there I could swap them around.

I found wherever I put the bad RAM, it failed, and wherever I put the good RAM it passed.

Here you cannot see the results as the bad RAM is at $1000, and that is used for the screen. You can however see the red and green marks in the colour RAM that confirm the good RAM is working in positions 6 and 7.

Six bad RAM chips.

I was a little reluctant to desolder and replace the six bad 2114 RAM chips.

The board seems quite fragile. I unfortunately damaged one trace removing the 74LS138. I am very sorry about that, and disappointed in myself. I managed to reattach the trace under the IC socket, so no harm done, but I wish I had not done that.

Traces on the top of the board are always tricky and almost all the RAM signals are on the top side of the board.

I cannot use a ROM/RAM board here because that only provides replacement ROM and RAM to the CPU, and the base 5K RAM needs to be visible to the VIC and the CPU (and also it would probably not fit in the case)

I did work out an alternative RAM replacement board that would plug into the character ROM socket with a single 62256 RAM chip to replace all 10x 2114 RAM chips in the base RAM. It would need a wire to connect it to another board in the 138 socket, and another to pick up R/W somewhere. The existing RAM chips seem to behave when disabled, so the modern RAM chip would do everything but the colour RAM (which seems to be fine).

Whilst I was pondering that, Bill sent me something else to be repaired, and also six 2114 RAM chips.

RAM Replacement

OK, here we go.

It took me about two hours to remove that. I really struggled to get all the pins free at the same time, and in the end, I decided to do something I do not like to do, but it seemed the best option in this case.

I had proved as far as I could that the RAM chip was bad, and I really did not want to damage the board.

So I cut off the legs of the chip.

It felt really bad.

But, it finally allowed me to get all the legs out cleanly.

One socket fitted. One new RAM chip. Fingers crossed.

Well, would you look at that. It was a bad RAM chip. It is 1K by 4 bits, so it only fixed those 4 bits. The other four are in the chip next to it.

Oh well. Those of a nervous disposition, look away now.

In for a penny, in for a pound.

Don't look, it's awful.

Cutting the legs off is really only a last resort. I would have liked the save the originals, even if it is just to retest them to prove they are bad. The chances of damaging the board were high, and the likelihood the chips were bad was equally high, so this seemed the safest option. In this case preserving the board was far more valuable than the saving the ICs.

All the bad RAM removed with no track damage, which was quite a relief. Working with single legs at a time holding them with tweezers and heating with an iron the legs were easy enough to remove. But it took many passes with lots of flux and desolder braid and resorting to the desoldering gun and even resoldering some of the pads to try to make the solder flow. Not a pleasant job, but easier than trying to remove the ICs whole.

Five more sockets fitted.

And then six of Bills 2114 chips. Not all matching, but all tested and working.

They are in sockets, so they could swapped if better matched ones are found in future.

That is assuming it works.....

Phew, was I glad to see that.

Testing

I left that running for a while, no problems were found.

I also used the Penultimate Cartridge self test for the soak testing. Again, all was working fine.

I went through quite a few games and everything seems to be fixed now.

The ROM chips are running a bit warm, as they tend to in VIC20s. Probably worth fitting some EPROM replacements and preserving the originals whilst they are still working.

The VIC itself is not that warm, so no need for a heatsink at this point, but it wouldn't hurt to fit one if you wanted.

Further Testing

I switched to using a Penultimate +3 to do the next round of testing.

That allowed me to test the IEC bus.

No problems loading from disk.

One of the oldest VIC20s playing one of the newest VIC20 games.

And just because I could, one of the oldest VIC20s next to one of the newest VIC20s.

All tested and ready to go back.

Important note on International Shipping

Shipping to the EU is once again going to be a problem, this time due to new GPSR regulations which appear to require considerable paperwork for every product I sell, in the language of any country I want to sell to, and with a named representative located in each of those countries. That is way beyound the means of my one man business. Like many others in my position, I am not going to be able to comply with the requirements and do not want to incur the fines for failing to do so.

It seems legislation designed to stop cheap and potentially dangerous imports from the far east is also going to kill off cottage industries and small makers selling on Tindie, ebay and Etsy etc. Hopefully they will sort this out and add a waiver based on product value or business size, and I will be able to ship again.

Oh, and it looks like America is likely to be adding import duties from some time next year, so get prepared for massive price increases and massive delays to orders as they put systems in place.

In the next few days, I will be setting I have set the store to UK only, I hope to open it back up to the US and the rest of the world early next year, and we will see what happens with the EU.

Advertisements

The Penultimate +3 with a built in SD2IEC drive is available from TFW8b.

Minstrel 2 and 3 kits and many of my PET repair and upgrade products are available from my Tindie store.

I will slowly be moving things over there from my SellMyRetro store, so if there is anything that you want, let me know and I'll add it.

More info can be found here:

Bluesky

For those interested in such things, I can now be found on Bluesky, and I expect to be posting more there.

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. If you want to see part two of this post, that is up on Patreon already. Also includes access to my Patreon only Discord server for even more regular updates.

Posted by at
Labels: , ,
Subscribe to: Posts (Atom)