Brass 3 and software PAL
Wednesday, 14th November 2007
My work with the VDP in the Sega Master System made me more aware of how video signals are generated, so thought it would be an interesting exercise to try and generate them in software. This also gives me a chance to test Brass 3, by actively developing experimental programs.
I'm using a simple 2-bit DAC based on a voltage divider, using the values listed here. This way I can generate 0V (sync), ~0.3V (black), ~0.6V (grey) and 1V (white).
My first test was to output a horizontal sync pulse followed by black, grey, then white, counting clock cycles (based on a 6MHz CPU clock). That's 6 clock cycles per µs.
The fastest way to output data to hardware ports on the Z80 is the outi instruction, which loads a value from the address pointed to by hl, increments hl, decrements b and outputs the value to port c. This takes a rather whopping 16 clock cycles (directly outputting to an immediate port address takes 11 clock cycles, but the overhead comes from loading an immediate value into a which takes a further 7). The time spent creating the picture in PAL is 52µs, which is 312 clock cycles. That's 19.5 outi instructions, and by the time you've factored in the loop overhead that gives you a safe 18 pixel horizontal resolution - which is pretty terrible.
Even with this technique, in the best case scenario you output once every 16 clock cycles which gives you a maximum time resolution of 2.67µs. This is indeed a problem as vertical sync is achieved by transmitting two different types of sync pulse, made of either a 2µs sync followed by 30µs black (short) or 30µs sync followed by 2µs black (long). In my case I plumped for the easiest to time 4µs/28µs and hoped it would work.
Anyhow, I made a small three-colour image for testing:
.
Of course, as I need to output each scanline anyway I end up with a resolution of 304 lines, which gives me rather irregular pixels, so I just stretch the above image up to 20×304. Eagle-eyed readers would have noticed that the horizontal resolution is only 18 pixels, but somewhere in the development process I forgot how to count and so made the image two pixels too wide.
As you can see, it shows (the entire image is shunted to the right). TVs crop the first and last few scanlines (they aren't wasted, though, and can be used for Teletext) so that's why that's missing.
A widescreen monitor doesn't help the already heavily distorted pixels either, but it does (somewhat surprisingly) work.
With a TI-83+ SE (or higher) you have access to a much faster CPU (15MHz) and more accurate timing (crystal timers rather than an RC circuit that changes speed based on battery levels) as well as better interrupt control, so on an SE calculator you could get at least double the horizontal resolution and output correct vertical sync patterns. You also have better control over the timer interrupts, so you could probably drive hsync via a fixed interrupt, leaving you space to insert a game (the only code I had space for checks to see if the On key is held so you can quit the program - more clock cycle counting). I only have the old 6MHz calculator, though, so I'm pleased enough that it works at all, even if the results are useless!
Brass 3.0.0.0 Beta 1
Monday, 5th November 2007
I've released a beta version of the new assembler. It comes with the compiler, a GUI builder (see the above screenshot) and the help viewer; it also comes bundled with a number of plugins.
I've also knocked together a quick demo project that can be built directly from Explorer once Brass is installed.

There are a number of missing features (such as a project editor, project templates and multiple build configurations) and no doubt broken, incomplete or untested components - but at least it's out in the wild now, which gives me an incentive to fix it!
Emulating TI-OS 1.15 and a greyscale LCD
Monday, 29th October 2007
OS 1.15 appears to boot, and if I run an OS in Pindur TI, archive the files (copy them to Flash ROM) then use that ROM dump in my emulator the files are still there, where they can be copied to RAM.
Trying to re-archive them results in a fairly un-helpful message, as I haven't implemented any Flash ROM emulation (nor can I find any information on it)...

Applications (which are only ever stored and executed on Flash ROM) work well, though.

I've also updated the LCD emulation a little to simulate the LCD delay; greyscale programs (that flicker pixels on and off) work pretty well now.


Brass 3 and TI-83+ Emulation
Friday, 26th October 2007
Brass 3 development continues; the latest documentation (automatically generated from plugins marked with attributes via reflection) is here. The compiler is becoming increasibly powerful - and labels can now directly store string values, resulting in things like an eval() function for powerful macros (see also clearpage for an example where a single function is passed two strings of assembly source and it uses the smallest one when compiled).
Thanks to a series of hints posted by CoBB and Jim e I rewrote my TI-83+ emulator (using the SMS emulator's Z80 library) and it now boots and runs pretty well. The Flash ROM archive isn't implemented, so I'm stuck with OS 1.12 for the moment (later versions I've dumped lock up at "Defragmenting..."). I also haven't implemented software linking, and so to transfer files I need to plug in my real calculator to the parallel port and send files manually.




Brass 3
Tuesday, 2nd October 2007
Quake isn't dead, but I've shifted my concentration to trying to get Brass 3 (the assembler project) out.

Brass 2 didn't really work, but I've taken a lot of its ideas - namely the plugin system - and kept some of the simplicity from Brass 1. The result works, and is easy to extend and maintain. Last night I got it to compile all of the programs I used for testing Brass 1 against TASM successfully.
I'm taking advantage of .NET's excellent reflection capabilities; one such example is marking plugin functions with attributes for documentation purposes, meaning that all you need to get Brass documentation is to drop your plugin collection assemblies (DLLs) into the Brass directory then open the help viewer app.

The source code examples are embedded as text, but compiled by the viewer (and thus syntax-highlighted) so you can click on directives or functions and it'll jump to their definitions automatically.
Native function support and a much-improved parser means that complex control structures can be built up, like:
file = fopen("somefile.txt") #while !feof(file) .db fread(file) #loop fclose(file)
The compiler invokes the plugins, and the plugins talk back to the compiler ("remember your current position", "OK, we need to loop, so go back to this position", "this loop fails, so switch yourself off until you hit the #loop directive again").
The compiler natively works with project files (rather than some horrible command-line syntax) which specify which plugins to load, which include directories to search and so on and so forth. There are a number of different plugin classes:
- IAssembler - CPU-specific assembler.
- IDirective - assembler directive.
- IFunction - functions like abs() or fopen().
- IOutputWriter - writes the object file to disk (eg raw, intel hex, TI-83+ .8xp).
- IOutputModifier - modifies each output byte (eg "unsquishing" bytes to two ASCII charcters for the TI-83).
- IStringEncoder - handles the conversion of strings to byte[] arrays (ascii, utf8, arcane mappings for strange OS).
Unlike Brass 2, though, I actually have working output from this, so hopefully it'll get released!
As a bonus, to compare outputs between this and TASM (to check it was assembling properly) I hacked together a binary diff tool from the algorithm on Wikipedia (with the recursion removed) - it's not great, but it's been useful to me. ![]()
using System; using System.Collections.Generic; using System.Text; using System.IO; namespace Differ { class Program { static void Main(string[] args) { // Prompt syntax: if (args.Length != 2) { Console.WriteLine("Usage: Differ <file1> <file2>"); return; } // Load both files into byte arrays (sloppy, but whatever). byte[][] Data = new byte[2][]; for (int i = 0; i < Data.Length; ++i) { try { byte[] Source = File.ReadAllBytes(args[i]); Data[i] = new byte[Source.Length + 1]; Array.Copy(Source, 0, Data[i], 1, Source.Length); } catch (Exception ex) { Console.WriteLine("File load error: " + args[i] + " (" + ex.Message + ")"); return; } } // Quick-and-dirty equality test: if (Data[0].Length == Data[1].Length) { bool IsIdentical = true; for (int i = 0; i < Data[0].Length; ++i) { if (Data[0][i] != Data[1][i]) { IsIdentical = false; break; } } if (IsIdentical) { Console.WriteLine("Files are identical."); return; } } if (Data[0].Length != Data[1].Length) { Console.WriteLine("Files are different sizes."); } // Analysis: int[,] C = new int[Data[0].Length, Data[1].Length]; for (int i = 1; i < Data[0].Length; ++i) { if ((i - 1) % 1000 == 0) Console.Write("\rAnalysing: {0:P}...", (float)i / (float)Data[0].Length); for (int j = 1; j < Data[1].Length; ++j) { if (Data[0][i] == Data[1][j]) { C[i, j] = C[i - 1, j - 1] + 1; } else { C[i, j] = Math.Max(C[i, j - 1], C[i - 1, j]); } } } Console.WriteLine("\rResults:".PadRight(Console.BufferWidth - 1)); List<DiffData> CollectedDiffData = new List<DiffData>(Math.Max(Data[0].Length, Data[1].Length)); for (int i = Data[0].Length - 1, j = Data[1].Length - 1; ; ) { if (i > 0 && j > 0 && Data[0][i] == Data[1][j]) { CollectedDiffData.Add(new DiffData(DiffData.DiffType.NoChange, Data[0][i], i, j)); --i; --j; } else { if (j > 0 && (i == 0 || C[i, j - 1] >= C[i - 1, j])) { CollectedDiffData.Add(new DiffData(DiffData.DiffType.Addition, Data[1][j], i, j)); --j; } else if (i > 0 && (j == 0 || C[i, j - 1] < C[i - 1, j])) { CollectedDiffData.Add(new DiffData(DiffData.DiffType.Removal, Data[0][i], i, j)); --i; } else { CollectedDiffData.Reverse(); break; // Done! } } } DiffData.DiffType LastType = (DiffData.DiffType)(-1); int PrintedData = 0; foreach (DiffData D in CollectedDiffData) { if (LastType != D.Type) { Console.WriteLine(); Console.Write("{0:X4}:{1:X4}", D.AddressA - 1, D.AddressB - 1); LastType = D.Type; PrintedData = 0; } else if (PrintedData >= 16) { Console.WriteLine(); Console.Write(" "); PrintedData = 0; } ConsoleColor OldColour = Console.ForegroundColor; switch (D.Type) { case DiffData.DiffType.NoChange: Console.ForegroundColor = ConsoleColor.White; break; case DiffData.DiffType.Addition: Console.ForegroundColor = ConsoleColor.Green; break; case DiffData.DiffType.Removal: Console.ForegroundColor = ConsoleColor.Red; break; } Console.Write(" " + D.Data.ToString("X2")); ++PrintedData; Console.ForegroundColor = OldColour; } Console.WriteLine(); } private struct DiffData { public enum DiffType { NoChange, Addition, Removal, } public DiffType Type; public byte Data; public int AddressA; public int AddressB; public DiffData(DiffType type, byte data, int addressA, int addressB) { this.Type = type; this.Data = data; this.AddressA = addressA; this.AddressB = addressB; } } } }
Removals are shown in red, additions are shown in green, data that's the same is in white.
