Sunday, 18 October 2026

Loading Programs on the Timex Sinclair TS1500

This is the Timex Sinclair TS1500 I repaired nearly a decade ago (how time flies).

It is a nice machine, basically a 16K ZX81 in a ZX Spectrum case for the American market.

I don't think it was a big seller over there and was never released over here.

That means it is NTSC, and as such slow mode is about half the speed of a PAL ZX81 (fast mode is identical on both).

OK, 54.8% if you want to be specific.

The ULA does have a pin for PAL/NTSC selection, but it would seem wrong to convert it, and there does not seem to be an easy way to do that, it looks like that pin goes under the ULA.

Internally, it is a minimal design with a type of ULA © Timex and marked NCR. It has 16K of RAM from eight 4116 DRAM chips, an 8K BASIC ROM and couple of buffer chips in place of a load of resistors.

The redesigned ULA takes on a bit more functionality than the Sinclair version, with it's 68 pins vs the original 40, mostly the DRAM multiplexing I expect.

It has also unfortunately got a ZX Spectrum style DC-DC converter for the RAM, but this one is still going strong.

Loading from Tape

I was interested to see how the cassette input was implemented, as it looked like there was a lot more going on than the ZX81.

When I was looking at tape loading on the Minstrel 4th, I did have a fourth part planned where I looked at ZX81 compatibles, like the Lambda 8300 etc., but I think everyone had had enough for those, including me, so I left it for a while so I can spring it on you unexpectedly, round about now.

TS1500 Tape Output Schematic

The TS1500 is one of the earliest and probably the only official ZX81 compatible machine.

In searching around, I found several schematics, all of which were unfortunately wrong in one way or another.

This one is almost unreadable, but does turn out to have the correct value the others have wrong.

This one has no values, but elsewhere has the part numbers are correct, where others are wrong.

This one is the clearest, but one of the values is wrong.

I have redrawn a combination of all of those which matches the actual board.

The value of R19 is shown as 1KΩ on the least visible schematic above, and that appears to match the ZX80 and ZX81 schematics. The actual board also has 1KΩ fitted, the relevant parts are highlighted below.

The ZX81 schematic has a larger value resistor on the signal from the ULA, 1MΩ rather than 510KΩ, but has the same 1KΩ to ground.

The TS1500 also has the 47nF capacitor in parallel with the 1KΩ resistor.

The three ZX81 boards I repaired recently all had slight differences around this area. The capacitor C11, is the large brown ceramic disc on this board, 47nF, and the 1KΩ resistor R27 is at the bottom.

One of the other boards looked to be missing C11 and R27 from factory, no evidence they were ever fitted, the pads are solder levelled like the other no-fit parts.

I then spotted they appear to have been fitted directly on the pins of the mic jack to the side.

A third board looked like R27 was not fitted from factory, but C11 looks to have been desoldered at some point and both are now by the jack socket.

Very odd. Would moving those really make that much difference?

Something else that is odd is the unusual ground arrangement on the TS1500. Rather than directly grounding the output jack, as in the ZX80, ZX81, ZX Spectrum etc., the TS1500 has a 100Ω resistor in the ground path. 

Confirmed by the actual PCB, the ground plane at the top is clearly connected to the ear jack on the right, but not the mic jack on the left.

Tape Input

A big difference to the ZX81 is it is an active input.

The ZX81 had a simple RC filter.

The TS1500 has a different RC arrangement, and then a transistor buffer.

A common mistake on several of the schematics was labelling C14 as C19.

It is sort of understandable as C19 is in the right place, but that is part of the tape out circuit, as shown above (and confirmed by tracing out the board). The 47pF capacitor is actually C14, just below the modulator.

As before, I have redrawn a version which matches the board.

This seems to do a reasonable job.

This is an inverting amplifier, and I have confirmed there must be an inverter internally on the input as the signal will not work if fed into a Minstrel 3 unless it is inverted first.

But as with any of these circuits, if the input signal is not very good, it will miss bits.



Practical Issues

I had an unexpected problem when trying this out.

Normally for loading, I use my TZXduino style unit to play .p files from an SD card.

As part of this testing, I also wanted to test loading from tape, but I couldn't find my usual tape leads.

No problem, I have any number of stereo jack to jack leads, that should be fine, I was using that on a Minstrel 4th last week.

But nothing loaded?

Odd, probing around on the board, there was nothing, no signals.

It was then I noticed the jack sockets.

These are the same style as used on the ZX81 and ZX Spectrum, and is designed for a mono jack plug.

On the Minstrel 3, I have the sockets wired to only the tip and the sleeve, with no connection to the ring.

A mono TS (Tip, Sleeve) jack has two connections.

A stereo TRS (Tip, Ring, Sleeve) jack has three connections.

With a stereo jack plugged in, I get the left channel on the top and the ground signal from the sleeve.

The right channel on the ring is not connected. You might think I should connect that in parallel with the left channel, but I that is a deliberate choice.

The reason is it also allows you to plug in a mono jack.

By connecting to only T and S, that will allow a mono jack to be connected with signal on the tip and ground on the sleeve.

If I had wired the ring in parallel, it would be shorted to ground on a mono jack,

Why Are You Telling Me This?

That all works fine with Minstrels and mono and stereo cables, so I am used to using them interchangeably.

I normally have a mono plug to plug lead for loading from tape, but I have lost that somewhere.

Not a problem as I have loads of stereo jack to jack leads.

When I offered up the stereo jack plug, the issue became obvious.

The problem is where the mono jacks are connected. On most tape decks, like the Sony TCM-818 I am using, the green jack connects to the tip and sleeve and does not connect to the ring. That seems the best option.

The TS1500, like the ZX81 and ZX Spectrum, use a different style of jack plug which I hadn't really considered before, but when you look at how the connections line up with stereo and mono jacks, you can see the problem.

There are only two connections. The signal input is on the tip, which is fine, but the position of the ground connection is where the ring is normally connected.

That means the tape is connecting ground to the sleeve wire and leaving the ring disconnected, but the TS1500 is ground referenced to the ring and does not connect to the sleeve.

I must have loads of those standard black and grey mic and ear leads for the Sinclair machines, but could not see any of them, nor any mono jack plugs.

In the end, I made up this lead using a couple of mono jack to phono socket adapters and a phono to phono lead.

Not ideal, but it worked fine as the sleeve of the mono jack extends to where the TS1500 connects to, and where the TCM-818 connects to and we can load games.

Yay, success.

Minstrel ZXpand II

Of course, there is another option.

The TS1500 has a standard ZX81 expansion edge connector.

I also recently released the Minstrel ZXpand II, which has onboard ROM, so no longer needs to connect a wire to the ROM select block, allowing it to be used on a ZX81 or TS1000 (with internal RAM upgrades) or the TS1500 (which already has 16K).

That means you can use the Minstrel ZXpand II with the TS1500 in several ways.

Edge Connector

The easiest option is the edge connector. This fits with the TS1500 and leaves access for the power and TV connectors.

However, it blocks the cassette connectors, which are lower than the RF jack.

The joystick is partly blocked by the power cable, so not ideal.

Minstrel Expansion Bus

The other option is to use one of the unpowered Minstrel Expansion Bus backplanes. These give four slots and a passthrough edge connector.

The Minstrel ZXpand II will then sit at the back and leave access to the RF, ear, mic and power sockets on the TS1500, and the joystick port on the Minstrel ZXpand II.

You also have four slots for various other expansion cards.

The Overkill Mega Bus

You could also combine a powered and unpowered Minstrel Expansion Bus and have 8 available slots, but also be able to power the TS1500 by an external power supply, if you prefer.

(you can't use the powered board directly as it clashed with the video and cassette jacks)

The Minstrel ZXpand II works fine with the TS1500, and you can load your usual favourite games.

Just remember that it is NTSC, so runs a lot slower than a PAL ZX81 which affects some BASIC games, most C or assembler ones are fine.

It also lacks support for some of the high resolution graphics modes that the Minstrel 3 supports.


All items are still available, and I can ship worldwide.

Including the Minstrel 2, 3 and Minstrel 4th (Jupiter Ace / ZX80 / ZX81 / Lambda 8300 / RC2014,) as available with built in keyboards.

Of to fit into a ZX81 case as a replacement mainboard.

All versions are available in kit form, or pre-built, and optionally the new Minstrel ZXpand II SD card and joystick interface.

Also the Minstrel Expansion Bus, powered and passive. If you want to add more cards, or do something like that shown in this post with the TS1500 and the Minstrel ZXpand II.

International shipping is a bit complicated at the moment, so if you want to order from outside the UK, please contact me using the contact link at the top of this page.

See here for more information:

Sorry to have to do this, and I know this is going to affect sales, but please understand it is the only option I have right now.

Stop Press!

I am going to do another batch of Mini PET 40/80s with keyboard, with a few updates. 

These are pre-order now, shipping worldwide in November. £450 kit / £500 built.

Available exclusively from me, contact me using the link at the top of the page to get a price for shipping and any duties, based on your address.

The Mini PET 40/80 internal PET replacement boards are also available now, £350 kit / £375 built.

Again contact me if interested.


Patreon

If you enjoy posts like this, you can support me via Patreon, and get access to advance previews of blog posts, and exclusive posts. Paid Patreon supports will be getting the third part shortly, and maybe a forth part three will follow if there is any interest

You also get progress updates on new projects and other behind the scenes updates, as well as access to my Patreon only Discord server for even more regular updates, and to discuss your own projects.

Posted by at
Labels: , , , ,

Sunday, 11 October 2026

VIC20 Bunny Blitz

As part of the testing of the current update to the Penultimate Cartridge, a lot of testing has been going on. This included a video from TFW8b where he went through 30 games in one hour using the built in "Rod's Random ROM Runner", which when enabled, will generate you a "random" game every time you press the reset button.

This was combined with an Arduino with a simple bit of code which automatically pressed the reset button every 2 minutes,

During that testing, RRRR carefully selected the game "Rabbit Blitz" by "C. Simun" for Rod to play.

Rod wasn't sure of the keys and managed to hit the RUN/STOP key, which because it was a BASIC program exited the game and left you at a READY prompt.

Because of the way the graphics had been done, none of those characters were readable, so it was all a bit of a fail.

Separately, during my testing, I had found that the game had a screen-shaking effect when you crashed, and that was leaving the screen set wrong for NTSC after the first crash.

Plan A

The simple plan, the one a sensible person would have chosen, would have been to take the BASIC program listing and make two changes.

The first would be to add in a POKE, such as:

POKE 788, 194

or

POKE 808, PEEK(808)+2

which would disable the RUN/STOP handler and stop that exiting to BASIC.

See the following posts for information on how those work:

The second would be to change the screen shake code.

The current version works by changing the value of vertical centering on the VIC chip rapidly between two values, and then resetting it to almost, but not quite, what the standard value should be.

The code in question was as follows:

Extracting out the relevant sections, 36865 is $9001, the address of the vertical centering register on the VIC chip.

POKE 36865,50

Sets this to 50, it then wait for a bit

POKE 36865,30

then sets it to 30.

Finally.

POKE 36865,40

Sets it to 40.

On a PAL VIC 20, for which this game was presumably written, the standard value is actually 38.

On an NTSC VIC20, the value is 25, and the grass is an interesting shade of green?

This means after the screen shake effect, the PAL screen is 2 lines lower, which you wouldn't normally notice.

However, the NTSC system is 15 lines out, so is pushed very low on the screen, still just about visible, but not ideal.

A simple fix would be rather than using

POKE 36865,40

to reset the value, instead it could either peek the value previously, store it and then restore it, or it could read the value from the KERNAL ROM, which is different for PAL and NTSC system, so would be correct. The value is at $EDE5, or 60901, so a fix would be

POKE 36865, PEEK(60901)

That that should be fairly straightforward.

But you know me.

Plan B

Rather than that, I decided to embark on an entirely different solution.

I would rewrite the game in 6502 assembler, fixing those issues in the process and tidying up a few other things as I go.

A combination of the arrogance of a long grey beard and also my intrigue at what the row of £ signs is about that appears briefly as the game starts.

And how exactly the game generates the city skyline using what appears to be an array of mostly inverse Q symbols?

It is 62 lines of BASIC, 1830 bytes. This should be a simple process to recreate that in assembler.

What Could Possibly Go Wrong?

Actually not that much.

I have the fall back of the simple BASIC fixes anyway, so I can just give up at any point and go with that. I could also just leave the game unmodified, as it has been since it was added to the cartridge 3 years ago and no one has noticed, or at least no one has complained about it.

No fake jeopardy here. I am not going to lose the shop if this doesn't work.

(actually, I am going to lose the shop if things don't pick up, but this short, self-indulgent dalliance into a little bit of notepad 6502 coding for a day or so is unlikely to affect that one way or the other)

As usual with these things, my tools of choice are a text editor and a command line compiler. In this case Visual Studio Code and ACME.

I started with a pretty much empty slate, the only given is the one line of BASIC code at the start, the line

6502 SYS4109

(the line number is irrelevant, but I always like to use 6502, because 6502)

I had some of my other assembler games open in another window for reference, so I could steal some of the system constants and any relevant code.

I also have a couple of web pages handy:

Which is a useful reference for the VIC20 memory map and things like the VIC and VIA registers and zero page addresses etc.

This is a handy reference for 6502 assembler as I occasionally need to check things like "does inc set the carry flag?" etc.

I followed the general structure of the code, at least initially. Once it was running, I shuffled things around where they felt most appropriate.

Save ££££££££s

The first thing I wanted to check was the spurious ££££££££ on the screen briefly at the top of the "PLEASE WAIT" title screen.

What was it waiting for anyway?

I did think it might be generating the skyline at this point, but that seems to happen on the fly when you complete a level and are presented with a new one.

Looking at the code, it was mainly lines 20 and 30.

20 fori=0to501:poke7186+i,peek(32768):next

Line 20 is odd. That takes most of the time, is responsible for the ££££££££ screen corruption and does not actually do anything useful.

If I load the game and delete line 20 before I run it, it still works fine, and starts much faster and without the £ signs.

30 fort=0to47:readd:poke7168+t,d:next

Line 30 is important. This reads some data statements in lines 40-90, and pokes 48 bytes of data into memory at 7168, note the "68", which is $1C00, a 512 byte area of code below the screen at $1E00.

Amongst other things, line 100 includes

POKE 36869,255

This sets the VIC addressing register 36869 ($9005) to 255, which sets the video to $1E00 (as it was), but the character data to $1C00 rather than the font ROM at $8000.

The code at line 30 defines six graphics used by the game, the parts of the building, the plane, the bomb. These are in positions 0-5.

The rest of the character set is the remaining 59 characters in $1C00-$1DFF, and then 64 characters from $1E00-$1FFF, which is the screen RAM, so those will be nonsense. Because of the way the VIC chips memory map wraps around, the last 128 characters are the first 128 characters in the font ROM.

On a standard VIC20, if I can run a bit of code to print out all 256 characters from the font ROM.

The first poke writes to screen RAM, the second sets the colour RAM to black so you can see it.

If I add that to the Rabbit Blitz program after the running the code with line 20 removed, I get the following. The horizontal lines come from the default initialisation values in the Vice editor. On a real machine, they would be random noise.

If I put line 20 back and run it again, I get stripes for the characters from 7-63.

Let's remind ourselves of line 20 (with some extra spaces added for clarity).

20 for i=0 to 501 : poke 7186+i, peek(32768) : next

This is setting 501 values from 7186 upwards (yes, that is 86, not 68 as before). This is easier to see in hex.

  • 7168 is $1C00, the start of character RAM here.
  • 7186 is $1C12, 18 bytes into the start of the character RAM.

18? I could understand if it was 48, that is the number of bytes used by the 6 custom characters, but 18 is two and a bit characters?

It also runs up to 7687 or $1E07, which is 8 bytes into the video RAM which starts at $1E00.

This explains the eight £ characters that appears at the top of the screen in the original game.

Why the £ sign? Well aside from the fact I do not know why the VIC20 has a £ character, on a dedicated key. The dollar is shift + 4, but the £ get's a key of it's very own. The PET didn't have £ at all. It has '\' at character $1C, the rest of the set is I think the same.

Not even the business keyboard PET had a £ sign, so why did the VIC20, a home computer for the US market get one?

Anyway, skipping over that, why the £ sign in this case?

Well, again it is back to line 20.

20 for i=0 to 501 : poke 7186+i, peek(32768) : next

For each of the 502 iterations of that loop, it reads the value at 32768 ($8000). Why?

Why not read it once at the start of the line?

Why even read it at all?

It is the first byte of the font ROM. It will never change, it is $1C on every VIC20. The top of the @ sign.

What is that even doing, it is just filling the character ROM with vertical stripes that are never referenced in the game?

I think it might have been originally something like this.

20 for i=0 to 511 : poke 7168+i, peek(32768+i) : next

This would read 512 bytes from the start of the font ROM at $8000 and copy them into the character RAM at $1E00.

You could then poke the new character data into certain characters and still retain the letters and numbers etc, if you need to write things to the screen.

For example, I have modified the code to do that copy, and to write the UDGs at positions 33 to 39, overwriting some punctuation.

There you see the UDGs are mixed in with the rest of the characters and you can type as normal.

I am not sure what happened with the game, was that the original plan and it didn't work for some reason? It just seems odd to leave that line in place when it is not doing anything useful, just adding a 10 second delay and writing eight £ signs to the top of the screen?

One possibility is to stop the program being listed? If you press RUN/STOP and type list, this is what you would get.

That is unless you type RUN and then press RUN/STOP on the title screen, or if you press RUN/STOP after your plane has crashed.

I could fix that by simply deleting line 20. But where is the fun in that?

Instead I recreated the whole game in assembler.

Where you are welcome to list the entirety of the code...

Tower Block Construction

One reason I decided to continue is that I was intrigued by the next set of lines. It seems to build up the screen using four strings which are mostly inverse Q characters?

Looking at the output of petcat, it shows those as {down} characters?

  120 a$(1)="{blk}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}e{left}{down}@{left}{down}@{left}{down}@{left}{down}@{left}{down}@{left}{down}@"
  125 a$(2)="{blk}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}e{left}{down}@{left}{down}@{left}{down}@{left}{down}@{left}{down}@{left}{down}@{left}{down}@{left}{down}@"
  130 a$(3)="{blk}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}e{left}{down}@{left}{down}@{left}{down}@{left}{down}@"
  135 a$(4)="{blk}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}e{left}{down}@{left}{down}@"

It is an interesting solution. It creates four strings at A$(1) to A$(4), then it generates a random number from 1-6 and prints that A$.

  200 fort=0to21
  210 print"{home}"tab(t);a$(int(rnd(1)*6)+1)
  220 nextt

Each one is preceded by {home} symbol and a tab(t).

It goes through 22 columns of the display. For each one, it goes back to the top left using {home} and then moves along to the top of the column (TAB is single characters here, not x4 or x8 as we might be used to).

It then prints the string which moves the print cursor down, down, down until it gets to where the building should be and then prints the building using E and @ for the UDGs at positions 0 and 5. After each printed character, it uses {left} and {down} to go to the next one.

The four strings are different height buildings, 6, 8, 4 and 2 blocks plus a roof each.

There is no A$(5) or A$(6), those are the gaps between buildings which I can now confirm will occur 1/3 of the time.

That is a very unusual way of doing that, I don't think I have seen that sort of thing before.

Scoring

On the original game, there were two numbers printed on the bottom of the screen.

It wasn't clear what these were. Maybe it was explained in the cassette inlay (if it was published) or magazine article (if it was a type-in), but I have found neither.

That might also have explained by the was called Rabbit Blitz. Where are the Rabbits? Was it released by Rabbit Software? Was it written by a Rabbit?

These are the result of another magic string of characters in line 1111.

1111 forh=1toz:nexth:print"{rvon}{blk}{home}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{down}{rght}{rght}{rght}"tb,b

This again goes to the top left and cursors all the way down to the bottom row, cursors right twice and then prints the TB and B variables.

I think those are "Tower Blocks" and "Bombs". TB increments whenever you hit a building, and B increments when you drop a bomb.

When you hit 30, it stops. Story of my life.

You get 30 bombs and that's it. Then all you can do is sit back and wait for the inevitable conclusion.

Oooof.

When you clear everything, you get to the end, and start again.

The bomb count is refreshed, but the building count persists.

It is not displayed on the screen, but there is a third variable used here, SC, presumably "SCore".

This is incremented each time you clear the field and land successfully.

There is a page which is displayed when this hits 10.

(Not that I have ever got there without cheating)

Introducing Bunny Blitz

I have re-themed my rewrite as Bunny Blitz, to make it a bit more cuddly as Blitz might be slightly out of favour after certain world events 25 years ago. #TooSoon?

I have taken the general look and concept of the game, but rewritten it from scratch in assembler.

I added symbols next to the buildings and bombs counters and displayed the score which was previously missing.

The bombs count goes red when it hits 30 and runs out (which inevitably happens when you are have almost completed the level).

I added more information to the "you crashed" page.

As well as a bit more on the "bunny" theme. I didn't have enough space for the full description of "patented lemon-scented building-cleansing bombettes", but I think that works.

As before, the "you won" page uses the same style.

I also applied that to the title page, to act as a sort of introduction to the game.

There is no need for a "please wait" as it only takes a second to setup the character set, which it has in fact done before the screen is displayed as it uses those characters.

I went for the character layout I described previously, a copy of the first 64 characters with the UDGs replacing the punctuation so I could combine them with text.

It looks rather pretty without the UDGs.

Game Mechanics

The rest of the game is a reasonably standard New York Blitz type game, nothing much to report.

The only oddity I found is that if you press the ↑ key it pauses the game until you press another key.

I had a few more ideas of things I could change, but decided not to over-complicate things.

One thing that always gets me with Blitz type games is the plane seems to pause (or in this case disappears completely) whilst the bomb is descending.

There was also the limitation in some games where the plane continues, but you cannot launch another bomb until the previous one has landed.

I did consider writing it so the plane continues and you can launch multiple bombs, but I thought that would add too much complexity.

One thing to note is the original game moves the plane on randomly 0-2 squares when it reappears, I guess to stop you holding down space and flattening the lot.

I also thought about making the plane land faster once you have cleared all the buildings, but that also seemed too complicated. It would need to keep checking if they had all been cleared.

Random Numbers

On the subject of random numbers, that was an interesting challenge in assembler, a random number from 0-5 and a random number from 0-2.

I had code in TimeBomb which was based on a routine George Beckett had dug up (more on that in the article)

That generates a 16-bit random number, as two 8-bit values, but I only needed 0-5.

I did think about masking it using 0000 0110, but that would only give me four values, 0, 2, 4, 6.

In the end I wrote some code to shift the 8-bit number 5 times, and each time add the shifted out bit to a running total.

If the number was 42, that would be 0010 1010, so my total accumulated would be 3.

The range would go from xxx0 0000, which was 0, to xxx1 1111, which would give 5 (as the final three bits would not be shifted out or counted).

That seems to work and gives a reasonable spread of pseudo-random numbers from 0-5.

I drew the towers is a more normal fashion. Starting at a point where the tallest building would be and stepping down 0, 2, 4 or 6 steps based on the random value, then drawing the roof and then stories below until it hits the ground.

This shows each of the four building heights.

Landing

I put that version up on Discord and to the TFW8b team.

One suggestion I got from Andy Hewco was the faster landing after clearing the level that I had previously ruled out.

Looking about it again, I realised I had been overthinking it. I added a counter each time a building was built, and decremented it each time one was knocked down.

When it reached zero, I descend to ground level, then cut the sound and taxi the plane off the screen to the right.

That's About It

The final version is 1688 bytes, still slightly shorter than the 1830 bytes of the original, but there isn't much it in with all the extra text I added.

I think it plays better, there is a bit more info on the screen and the graphics are less flickery. And gone is the startup delay and ££££££££ over-spill and on NTSC there is no misalignment after the first crash (but nothing I can do about the grass colour).

I will be adding that to the Penultimate Cartridge release candidate, but for now I have put this up on GitHub, along with the commented source. All written by me, by hand. No sloppy AI coding, just some hopefully not-too-sloppy human coding.

If anyone wants to give it a go on a real unexpanded VIC20 or your emulator of choice, let me know how you get on and if you have any suggestions or feedback, or any other games you think could be similarly reworked.

Adverts

The VIC20 Penultimate Cartridge +3 DCR is available now from the Future Was 8 bit.


All Tynemouth products are still available, and I can ship worldwide.

Including the limited edition 10th anniversary recreation of the very first Penultimate Cartridge:


International shipping is a bit complicated at the moment, so if you want to order from outside the UK, please contact me using the contact link at the top of this page.

See here for more information:

Sorry to have to do this, and I know this is going to affect sales, but please understand it is the only option I have right now.


Patreon

If you enjoy posts like this, you can support me via Patreon, and get access to advance previews of blog posts, and exclusive posts.

You also get progress updates on new projects and other behind the scenes updates, as well as access to my Patreon only Discord server for even more regular updates, and to discuss your own projects.

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