When I bought my Amiga A500 from TradeMe it came with a compatible monitor which had some old-monitor problems related to picture quality. I expected that as CRT monitors do tend to deteriote in quality over the years and also tend to die suddenly.


I was not proven wrong as the monitor did die a few weeks later with a click and a whine.

The Amiga A500 has a video-out port but puzzlingly it outputs in greyscale only.

I searched for how to connect the Amiga to a modern monitor using either RGB or HDMI and found that the only indirect way to do it is using an ugly commodore Amiga adapter device called A520 which provides an RCA video-out signal in color as well as RF out.


Someone was selling a pair of these on ebay so I got them, they both worked but one of them seemed to need some maintenance as it required a bit of fiddling around when plugged in to output in color. Sometimes it insists on only outputing blurry greyscale.

I ran the output to an LCD TV using RCA video and audio out, both produced awful blurry quality picture that made it very difficult to read any text. Since then the Amiga was all but unusable.

Modifying A520 to output S-Video

I had to decide what to do with the Amiga (either sell it or find a way to get good quality output making it usable again), when doing a quick search I found this great step-by-step guide for converting the A520 to output S-Video signal which should make it usable again.

I decided to try it. Ordered all the electronics components needed 2 weeks ago and when they arrived setup a work area and spent a day going through all the steps. After many hours and 3 solder-iron burns I got it done. I just needed to test it.

S-Video to RCA Video Out

S-Video output means I get two signals out of the modified A520 one called Chroma (letter C) and one called Luma (letter Y for some reason). It wasn’t clear in the guide how to convert that to a single RCA video-out signal, there are commercial S-Video to RCA converters but I felt since I went this far might as well try adding the conversion to the circuit.

Upon googling, I was surprised that this conversion requires a single component and it’s extremely easy to do! Just a single capacitor 470 pF across the Chroma and Luma outputs.


Did a quick breadboard test and voila! It got video out to display on TV:



The difference was very clear even through my phone’s camera:


Adding that capacitor to the output then rewiring and reseating the board, and we have a modified A520 ready for use:


I left it running for several hours to make sure everything is working as it should




01 June 2018




SPRITESR is a work-in-progress sprite library to automate drawing and animating sprites. SPRITESR is written to work specifically with N66 SR Mode 6 Screen 2 (Warka PC-6002, NEC PC6001 Mk2 SR, NEC PC-6601 SR, and NEC Mr PC).

SPRITESR Demo: disk for N66 SR emulator

To run the demo in the emulator, insert floppy disk image, go to mode 6 then type:


SPRITESR Git Repository Here.


SPRITESR provides 8 sprite slots that auto-redraw on VSYNC at half rate (30 fps).

Sprites coordinates can be dynamically updated and actual bitmap data can be changed to allow multi-frame animations.

SPRITESR works best for 8x8 pixels sprites but there is no hard limit, it can draw any size of sprite defined with two conditions: height must be divisible by 2, and width must be divisible by 4.

However for larger than 8x8 sprites flicker may occur.

SPRITESR allows specifying which sprites were changed this frame by calling the procedure SPRITESR_SETREDRAW. It will only fully redraw changed sprites and skip clearing unchanged sprites (useful for minimizing flicker slightly).


The library is currently made up of the following modules:

  • n66sr_bios.asm: definitions for a number of N66 SR BIOS calls (addresses) and useful system constants.
  • vsync.asm: vsync user event setup utility.
  • fastclear.asm: fast screen 2 clearing procedures covering all 3 areas of VRAM.
  • spritesr.asm: fast sprite drawing in direct VRAM accessible rectangle in screen 2 which starts at 0, 12 and has width/height of 256x188. PNG60 was updated with new functionality to support exporting p6bmp binaries directly usable by SPRITESR.

The demo is made up of the following modules:

  • picard.asm: actual demo code setting up all sprites, reading input, and updating sprites accordingly.
  • sprites.asm: definitions for a number of test sprites with different sizes.

Implementation Details

SPRITESR is currently written entirely in z80 assembly and doesn’t make use of COMPILE60 tool yet.

I went through multiple attempts to implement fast sprites, for the life of me I still can’t figure out what’s wrong with VRAM in SR screen 2.. for some reason writing directly to rectangular area 0,0 to 255,11 or 256,0 to 320,200 just produces garbage despite the memory map clearly being marked for those areas in all information I found.

The VRAM layout is also odd. Each 2 horizontal pixels are directly equal to 1 byte but these pairs of pixels are arranged in 8 pixel blocks (4 bytes of memory) representing 4x2 pixels on screen:


When drawing sprites, rather than doing it pixel by pixel it’s done by block where every 4x2 pixels make 1 block which means width and height of sprites must be divisible by 4x2.

This produces very fast drawing approaching hardware sprites performance although things get costly quickly the larger the sprites get. As a consequence of drawing blocks of pixels the animation must be done in steps of 2 pixels for both horizontal and vertical movement.

For the garbage areas at the top and right there are two ways to write pixels correctly:

  1. Output Y coordinate to 2 special ports: 0xce (low) and 0xcf (high) and read/write pixels from/to X coordinate 0 to 320 mapped directly to address 0x0000.
  2. View screen 1 (text screen) and set screen 2 as work area. When writing data directly to screen 2 vram in this case it works flawlessly but you can’t see screen 2 in the meantime so this isn’t useful.

First method always works perfectly but is noticeably slower as 2 bytes need to be output for every horizontal line.

Introducing VSYNC

The missing piece in the puzzle was how exactly to eliminate or at least minimize flicker?

In N66 mode you get multiple pages and the ability to set which page is viewed instantly and also set which page to work on and video memory will update accordingly.

This allowed a straight forward double buffering drawing technique, no need to interrupt on VSYNC and time drawing correctly.

In N66 SR you only get a single graphics page, so double buffering is no longer possible.

While searching for information about the platform online I ran across TinyYarou’s blog where he writes about his projects for the P6 platform, in one particular blog post he demonstrates a project he did in N66 SR BASIC and briefly mentions something about VSYNC interrupt usage.

I could not find any information I could use about what’s that interrupt’s address, nor how to set it up and use it. I sent him a message through twitter and he replied with a perfect assembly code snippet showing exactly what I’m looking for!

I immediately put together a demo and it worked! no more flicker or at least a lot less compared to just directly redrawing sprites.

This became the basis for SPRITESR’s current sprite drawing and animating method. vsync.asm module is mostly based on that code snippet.


  • Due to how VRAM in SR screen 2 work, sprites are limited to rectangular area starting at 0, 12 with width/height = 256x188.
  • Sprites are cleared using background color specified, meaning the background must be a solid color.
  • Sprite overlap is problematic as background clearing will overwrite sprite pixels below.
  • No transparency is supported.
  • Sprite movement horizontally and vertically can only be 2 pixels at a time due to the VRAM layout.

Planned Features

  • Allow supporting simple dithered background clear colors.
  • Attempt implementing some sort of transparency with minimal performance impact.
  • Implement simple overlap detection between user-marked sprites.
  • Simple tile map support, each tile is 16x16 pixels and may be used for clearing sprite backgrounds if performance impact was acceptable.
  • Tile map scrolling support using the ROLL hardware scroller available in SR, single direction only horizontal or vertical.

Procedures List

VSYNC Module (vsync.asm)

  • SETVSYNCEVENT: start vsync event
  • ENDVSYNCEVENT: end vsync event

VSYNC event automatically calls event: VSYNCEVENT (implemented in SPRITESR)

FASTCLEAR Module (fastclear.asm)

  • CLEARSCREEN2: slow clears all screen 2.
    • Set clear color: register C (0x0 to 0xf)
  • FASTCLEARSCREEN2: fast clears sprite rectangle in screen 2 @ 0, 12 (256x188).
    • Set clear color: register C (two 16 colors 0x00 to 0xff)
  • CLEARSCREEN2TOP: slow clears screen 2 top area.
    • Set clear color: register C (0x0 to 0xf).
  • CLEARSCREEN2RIGHT: slow clears right area of screen 2.
    • Set clear color: register C (0x0 to 0xf)
  • FASTCLEAR: fast fill memory using given value.
    • Start address: HL
    • Size high byte: D
    • Size low byte: B
    • Clear value: C

SPRITESR Module (spritesr.asm)

  • Sprites data init and update: SPRITESR_DATA0 to SPRITESR_DATA7
  • SPRITESR_SETREDRAW: mark sprite updated and should be redrawn this frame.
    • Use sprite index: register A (0 to 7)
  • SPRITESR_REDRAWALL: mark all sprites updated (full redraw) this frame.
  • FASTDRAWSPRITE: draw a sprite exported by PNG60 for mode 6 (-6 -f flags).
    • Sprite data address: HL
    • X coordinate: C
    • Y coordinate: B
  • FASTCLEARSPRITE: clear sprite are using given color.
    • Sprite data address: HL
    • X coordinate: C
    • Y coordinate: B
    • Clear color (two pixel colors 0x00 to 0xff): A

Next Objective

Compile SPRITESR as a usable z88dk library. Implement the same bouncy sprites demo in C.



31 May 2018




COMPILE60 is a simple front-end I wrote in Python/Tkinter to simplify C compilation and linking of PC-6002 projects.

Installation and usage instructions are in the readme.md file: COMPILE60 git

COMPILE60 requires z88dk to work and of course a PC-6001 emulator to run the binaries.



  • At the moment, N66 SR (Mode 6) support is listed but it doesn’t exist in z88dk yet (working on it).
  • Limited options that don’t include more advanced features like optimization

A few planned features to be implemented some day:

  • Compiling output directly into a virtual floppy disk image rather than using P6 cassettes
  • Embedding support for PNG60 tool to import and compress bitmaps to N66-BASIC


13 May 2018




I expected a troubled commercial history for the PC-60 due to the limited information about it, but I wanted to understand why and I’ve been researching the history of the PC-60 platform in Japan this last week.

My main source of information was the only related magazine I was able to find online in archive.org, IO Magazine. In every issue starting around page 200 there is an impressive amount of technical information about multiple platforms from that era as well as entire source code listings for software and games for these platforms.

Armed with a Japanese OCR solution and Google translate, I went through all issues from 1984 to 1986 and collected all PC-60 information and source code I was able to find.


Here are a few things I learned:

  • Last generation of PC-60 was not a very successful platform in Japan. It was out around the end of 1984 and advertised actively for 6 to 7 months afterwards. Then focus shifted towards PC-80 and PC-88 which were much more successful and lasted until the late 80s.
  • Besides PC-6001 Mk2 SR and PC-6601 SR there was another variant branded: NEC Mr PC that shared the BIOS and N66 SR BASIC. Mr PC failed outright it seems, it was only advertised for a few months then disappeared completely.
  • The naming system is greatly confusing. Instead of numbering their systems incrementally NEC just kept adding random letters and numbers which I’m sure didn’t help and caused a fragmentation in the userbase.


So no surprise there, the userbase was limited in Japan and only around 4 technical books were published about PC-60 SR, I found none of those online.

New Information about the platform

  • PC-6001 and its later variants were targeting students. PC-6601 and Mr PC were targeting more advanced users and included a special mode that allows overlaying an external video signal as background. PC-8001 was for business and commercial applications. The successor to all of them turned out to be the PC-8801 which had many variants in the following years all using N88 BASIC.
  • In N66 SR BASIC, There are a group of BASIC instructions that spit out a strange NA ERROR if you attempt to use them. NA stands for Not Available which simply indicates the instruction’s triggers are there but they are not doing anything. Apparently there is a version of N66 SR that comes on disk which implements all these extra instructions.
  • All Microsoft BASIC implementations were designed to be extensible. So you can actually add your own instructions or extend existing ones if you have all the info, and I’ve seen a couple of projects in I/O magazine that do just that, the most impressive is a full Z80 assembler implemented as a BASIC interpreter extension.


Technical Information

The amount of technical information I was able to find about the PC-60 platform is severely limited and exclusively in Japanese. I have not found a single dedicated detailed overview of the internals of the platform, just fragments here and there and a few books for PC-80 platform which I can only guess uses a similar BIOS.


Another potential source of technical information I found was a conversion tool for PC-80 games to PC-60 that the Japanese PC-60 community developed. These are available online and they use assembly code commented in Japanese. Here’s Wizardry 1 conversion kit for example. I tested one of the conversions and the result tested the limits of the emulators, it was glitchy! but it used all SR features which makes it a good target for reverse-engineering.

The last and most direct source of internal technical info for N66 BASIC (excluding SR) is support for PC-6001 in the z88 development kit which includes a standard C library, graphics, floating-point math, joystick, PSG sound, and even a simple sprite library.

Therefore and in order not to reinvent the wheel, I decided to switch from SDCC to z88dk for my C pipeline and I am working on a build tool and vscode integration.

Once everything is working, I will start implementing support for SR and extending the z88 devkit to include more graphics features and FM chip access (Yamaha YM2203).



07 May 2018




The PNG Pipeline

The first utility I wanted to build was a set of tools to convert any appropriately scaled-down PNG to be viewable directly in PC-60 BASIC.

I’ve used Python for the scripts that convert and generate the necessary data plus the 3rd party tool txt2bas.exe available online.

I was able to draw directly using the PC-60 palette using this palette profile I made for Paint.Net, then convert the PNG to a BASIC program for display.

I drew this small logo for PC-6002, here it’s getting unpacked in the emulator in Mode 5:


When I started experimenting on converting larger PNGs I immediately ran into RAM limits, back then this used to be a major bottleneck in my projects. The palette in PC-60 is tiny (16 colors) and as a result there are many repeated bytes in the pixel data, so I developed a simple RLE compression-decompression method in Python and ported it to BASIC. It was pretty effective I was able to load bigger more-detailed images.


The pipeline I went with to achieve all required features is pretty straightforward:

  1. PNG60.py: script to read a PNG, make sure it’s compatible, map all its colors to the closest colors in the PC-60 palette, then exports the resulting color data as a binary color list that matches PC-60’s video memory layout. It supports Mode 5 and 6. It outputs binary files using extension: “.p6bmp”
  2. p6bmp2bas.py: this is the workhorse in the system, it reads PNG60’s output binary files and pre-processes them first for PC-60 applying optional RLE compression. Then generate a BASIC program that includes all required code to display the bitmap as well as the bitmap data. It outputs the basic program as a “.bmp.bas” file.
  3. txt2bas: this is a tool developed by japanese PC-60 developers and is available online. It simply converts the BASIC program generated by p6bmp2bas script to a .p6 casette file that can be loaded directly in any PC-60 emulator using the “cload” command and then executed using the usual “run” command. The two supported modes are: Mode 5 Page 3, and Mode 6.


These tools are all grouped into a package usable via a few batch files I wrote to automate all the stages of the pipeline and directly output the .p6 file from a PNG file.

I setup this repository for the pipeline package (folder “PNG60”) and I will be constantly updating it with any new stuff I develop in the future.

Planned Features

I’ve pretty much implemented most of what I wanted to experiment with however the size/detail of PNGs I can convert over to PC-60 is still limited by memory even after RLE compression. I would like to reimplement the last stage of the pipeline to directly export to loadable binary data on a floppy disk (using BASIC’s BLOAD command) which is much faster and allows loading full-screen bitmaps directly.

Additionally, the current method to convert colors to PC-60 palette is just a simple RGB comparison to figure out which PC-60 color is the closest. As a result, many colors in exported bitmaps get approximated to gray which is right in the middle of the RGB range. I’d like to make sure to use the whole 16 colors palette and do some half-tone/dithering to fake more colors.

Next: I’ll be working on ditching BASIC for C/Assembly-programming and expand on this reference page I’m writing.



02 May 2018