Veronica Gets A ROM Monitor

monitor

[Quinn] has been on Veronica, her 6502-based computer for quite a while now, but until very recently it’s been more of an embedded project rather than a fully functional computer. Writing software for Veronica on Veronica has been the goal from the start, and finally [Quinn] can write code from a ROM monitor.

In its most basic state, a ROM monitor is an extremely simple piece of software. It resides on the ROM of a computer and is the first thing the computer loads on booting, allowing the user to inspect, read, and write to memory locations, writing code in hex, and running it straight from the monitor.

To write the ROM monitor (and a few other programs), [Quinn] is using the awesome cc65 6502 C compiler. This comes with a whole bunch of macros that make it easy to read keyboard input, shove bits into her AVR GPU, and writing to memory. The monitor program is loaded onto her ROM chip which is automatically read every time the reset button is pressed.

In the video below, you can see [Quinn] writing a few bits to address $2000 that tell the CPU to output ASCII characters to the display. It’s not much, but it’s the first time [Quinn] has written code for Veronica on Veronica, and should prove to be the beginning of a very interesting system.

18 thoughts on “Veronica Gets A ROM Monitor

    1. From what I remember reading about her while stalking^H^H^H^H^H^H^H^Hresearching her I think she’s up in Washtington, a bit far away from LA where the live event was. I’d have loved to see Veronica too. I might have tried to bring my own program to throw on her, (very probably 99 bottles of beer).

  1. Forgive my lack of knowledge on the subject, but I couldn’t help but notice that the number 42 was populating what I believe were unprogrammed ROM addresses. I would have expected to see 00 or FF.

    Would that be a tip of the hat to Douglas Adams?

    Again, I’m sorry if this is a stupid question.

    1. She likely cycles through a bunch of values to get a good test. One of the fun things that can be missed if you use just 00 and FF is when data or address pins are shorted together on accident.

      1. Speaking of which, I wonder if she’s programmed a memory test using an LFSR to detect shorted address pins.

        Basic idea is that you use the LFSR (or any other random number generator, but an LFSR is easy to do in a hardware register or two) and fill the contents of ram with different numbers, then read it back and start the LFSR over and compare the entire contents of memory, that’ll let you know if there’s shorted address lines or even missing address lines.

    2. 42 (hex) shows up because it’s left behind in RAM by the RAM test program. Blank, unprogrammed EPROM would indeed be FF (hex).

      As for the 6502 code, it all takes me back to 1980 and the Compikit UK101, typing in hex op-codes because I had no assembler. At one point, I typed in 6k of hex for the FIG-Forth system, from a listing (I probably still have it on cassette somewhere). I recognised a few hex op-codes from the Veronica screenshots…

  2. One small clarification- cc65 (ca65, actually) has a macro language. It doesn’t come with any actual macros, particularly for things like reading the keyboard. That was quite a lot of work to write. :)

    I was actually intending to bring Veronica to The Gathering, but the tickets were gone too fast for me to get one.

  3. Oh, and yes, the 42 is a Douglas Adams reference. I needed an arbitrary recognizable bit pattern as part of the RAM diagnostic. Most of RAM ends up filled with it by the end of boot up.

    Untouched RAM usually has FF in it, but not always. There’s occasionally random garbage here and there.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.