Oric Screen Editor: Porting a screen editor for the C128 to the Oric

November 26, 2022

Introduction
What is Oric Screen Editor
Why I created Oric Screen Editor
Reception of VDC Screen editor and porting it to the Plus/4
Journey and challenges in creating the Oric version
Toolchain used
Referenced URLs:

Introduction

(Article published earlier in CEO Mag 367 (only downloadable for CEO members) )

24 August I released my new utility, Oric Screen Editor via the Defence Force forum and the Facebook Oric groups. In his article I like to tell why I created this tool and explain my journey in developing it.

What is Oric Screen Editor

Oric Screen Editor is an editor to create text-based screens for the Oric Atmos. It fully supports using user defined character sets.

Main features of the program:

Support for screen maps larger than 40x27 characters. Screens can be up to 8 KiB (8.192 bytes), all sizes fitting in that memory with width of 40 at minimum and height of 27 at minimum are supported.
Supports resizing canvas size, clear or fill the canvas
Support for loading user defined charsets (should be standard charsets of 96 characters of 6 bits width and 8 bits height, alternate charsets of 80 characters or combined charsets of 176 characters).
Includes a simple character editor to change characters on the fly and directly see the result in your designed screen.
Supports the Oric serial attributes for ink, paper, and character modifiers (standard vs alternate charset, double height, blink).
Write mode to freely type characters with the keyboard
Line and box mode for drawing lines and boxes
Select mode to cut, copy, delete or repaint (only color or all attributes) the selection.
Move mode to scroll the screen contents (due to memory constraints only for the 40x27 viewport)
Palette mode, including visual charmap mode, to visually select characters and colors
Favorite slots to quickly select 10 favorite characters

OSE Title Screen

OSE Screen 1

OSE screen 2

OSE screen 3

Why I created Oric Screen Editor

When I rediscovered a liking to program for my 8-bit computers, I have started by revisiting the programs I wrote back in 1991 and 1992 for my Commodore 128 computer in BASIC. I thought it would be a nice challenge to port my version of the boardgame Ludo I had written for the C128 in BASIC to the Oric, first in BASIC, using OSDK, later in C using the CC65 C cross compiler. I have released this game last year for the Oric and after that ported this version also to the Texas Instruments TI-99/4a and even back to a new version for my C128.

Developing in C has the very nice advantage that code is very portable. Obviously CC65 itself already supports both the C128 as the Oric Atmos as target, but even porting the game to the TI, with a completely different CPU, proved to be very feasible using a C compiler for the TI.

Biggest challenge of course is programming graphics, as the implementation of even simple text graphics is wildly different on those various platforms, especially if you want to do it in color and with user defined character sets. Programming those is one thing (was fun to dive in how to code low level for the different video processors) but porting the program to a new target at first also requires redesigning the main screen with the constraints of the new platform. To redesign the main screen of Ludo for the Oric Atmos version, I used Twilighte’s CD2, as that was basically the only tool (and also proved to be a very nice tool) to design text screens for the Oric.

For my next project after completing Ludo, I wanted to do a boardgame where the board certainly would not fit in the 80x25 C128 screen (for the 80-column mode of the C128). So, I needed a text screen editor for my own needs that supported bigger screens than 80x25 and supported user definable character sets. Searched for it online, found plenty of such tools for the Commodore 64, but nothing that supported the specifics of the C128 80 column VDC chip.

That is why in summer 2021, I decided to code such a tool myself. The Oric CD2 tool by Twilighte was a big inspiration, as that tool basically showed me what I wanted, apart from CD2 also not supporting bigger than just one normal text screen. Two weeks of COVID quarantine (two kids after each other testing positive) also helped in me finding the time for it. That tool became VDC Screen Editor for the C128. I started by coding basic machine language routines in assembly for the core screen routines, coping specifically also with copying a viewport from a bigger than 80x25 screen and scrolling that viewport around, as C code would be to slow for that core part. The rest of the program is written fully in C, using again CC65. Biggest challenge was to find out the options to make the most out of C128 memory management to try to make the most optimal use of the 128 KB memory on the C128, but reading manuals and spending time on forums helped a lot there.

VDC Screen Edit screenshot

Reception of VDC Screen editor and porting it to the Plus/4

As indicated, I created VDC Screen Editor purely for my own needs from frustration that such a tool was not already there. But to my surprise, reception of my program was rather favorable. I still consider myself a novice programmer especially in assembler, so suddenly getting favorable mentions and praise from what you consider to be legends from the C64 coder community is a big motivating factor. Especially if a noted C64 graphician from the demo scene actually is using your tool as he always wanted to try doing PETSCII graphics in the C128 80 column mode.

Gaining feedback from someone that is using your tool to create new art is also very valuable to improve the program. The idea for the palette mode in the editor with a visual instead of numerical order of the PETSCII characters came from him, next to some important other usability tweaks.

As at that time I also gained a Commodore Plus/4 to my collection, the idea came to me to port VDC Screen Editor to the Plus/4, also because I wanted to try the 121 colors on that platform. Porting the code to the Plus/4 proved to be rather easy, as even on kernel level, Commodores are pretty much all the same. In the C code using CC65, you can use the same commands for things like disk IO for all Commodore targets. The only thing that needed low level changes is memory layout to deal with 64KB versus 128KB and dealing with the PET video chip of the Plus/4 versus the VDC chip of the C128. But as the VDC chip is way more complex to code for than the TED chip (or the C64 VIC-II chip for that matter), even porting the assembly code proved to be not much more than just deleting all the complexity needed for the VDC, leaving rather simple memory move routines. So creating TED Screen Editor for the Commodore Plus/4 proved to be relatively simple.

TEDSE Titlescreen

Journey and challenges in creating the Oric version

As porting to the Plus/4 proved to be rather easy, and after also receiving positive reception on that port, I decided to continue and make an Oric Atmos port. I thought that that should be also relatively simple, as CC65 of course also has the Oric as a supported target and the 6502 assembly routines should be rather the same for the Oric.

Of course, my first challenge on the Oric port was how to deal with the Oric method of ‘serial attributes’. The Commodore targets all have separate memory for storing color and other screen attributes, the Oric all does that within the same memory space, where every color or other attribute change costs a memory spot where no character can be stored. On one hand this solved some of my problems. With separate attribute memory, storing every single character costs two bytes, one for the character code, one for the attributes. On the Oric, this is not the case, so this halves the memory needed for a screen of the same dimensions. Solely for this reason, coming down from 128KB on the C128, to 64KB on the Plus/4 to 48KB on the Oric proved to be not that big of an issue (although my final version of Oric Screen Editor now crams that 48KB to the maximum I now have the understanding to use). Also, it further simplified my assembly code, as I now had no need to have two memory copy or moves every time, instead of characters and attributes, now only that one memory space. But of course, this also brought constraints on the implementation of the functionality of the program. Some tools within the program needed a redesign to cope with dealing with serial attributes. That took some effort to try what was working best (in my opinion at least).

Next challenge was disk IO. CC65 has no disk IO access functionality for the Oric Atmos target at all, as the use of disk drives for the Atmos is both too rare as not standardized. For Ludo, I used the SEDORIC functions of the oricOpenLibrary of Raxiss. Works great to support SEDORIC commands in C but has the downside of having no error handling at all. Solved that for Ludo by using save slots, so no user error in the filenames could be made, but that would be very restrictive for a screen editor in which I would also like to be able to import stuff from other disks and to be flexible in filenames on saving stuff.

To brainstorm on solutions to tackle that, the Defence Force forum is great. I just created a topic on my issues, and the suggestions came in. As I at that time also thought Oric memory would not suffice for a port, I started in exploring ways to use overlay RAM and not use SEDORIC altogether but use the Disk Builder tool. I got stuck in exploring that, my code was not working. Might pick that up some time, as of course that approach should also work.

But in that topic, Iss (the Iss part of Raxiss….) came with another thing he recently made, an extension to oricOpenLibrary called lib-basic, allowing the use of Oric BASIC commands from C. Brilliant. Instead of writing C functions to use SEDORIC, just use the SEDORIC BASIC commands. Code becomes actually smaller with that, with more functionality. Downside was that error handling became even more awkward, with throwing you to a BASIC prompt without any means by the C code to recover from that.

Brainstorming in that topic, together the idea evolved to try to solve part of that to use the output of the SEDORIC BASIC DIR command to create a file picker. That has the big advantage that user error on entering filenames of files to load is reduced to almost zero. Brilliant idea, code to use that was rather easy and quick to make. But that BASIC DIR command obviously take no care at all to my careful screen design and did also fully ignore cursor positions of my C program. I had a working workaround but having a disk with too many files on it that would cause the output to scroll the screen would still create chaos.

Further brainstorming and realizing SEDORIC actually loads itself in RAM (namely the overlay RAM) gave the idea to actually patch SEDORIC in RAM, so the output of the DIR command is routed to my own routine instead of the normal screen print routine. This was much helped by the full disassembly of both the ORIC ROM as the SEDORIC3 code being available in the DF Oric Library.

This is how the present filepicker functionality in Oric Screen Explorer came to be. It certainly still has its limits, as the parser can not handle any output other than a standard SEDORIC3 disk image created with the TAP2DSK tool, and still does not do error handling, but at least for my own needs this is now very usable. Hopefully for others as well.

2020-12-21 15-21-42 UTC

retro-setup-3

retro-setup-2

Toolchain used

I presently use this tool chain for creating my Oric programs:

Windows 11 PC running Ubuntu using Windows Subsystem for Linux 2
OSDK tooling (mainly the Linux versions of Oricutron and HEADER, TAP2DSK and OLD2MFM) for Linux using this guidance
CC65 Linux install
HxC Floppy Emulator tooling for Linux to create HFE images
A Linux makefile to combine all tooling in one automated chain
For real hardware testing, a real Oric Atmos with a Cumana Reborn disk drive emulator, and an RGB2HDMI to capture video from this Oric Atmos
All source code, disk images and documentation of Oric Screen Editor can be found at https://github.com/xahmol/OricScreenEditor