Running Cheese and Chive from ROM on a Mini PET

Some days, you have a great idea, it is easy to implement and works straight away. 

This was not one of those days.

Background

The standard Mini PET 40/80 comes with a 27C040 ROM with 8 ROM images. These include various versions of BASIC and test programs, all for use with the normal layout keyboard that is built into the Mini PET.

The Mini PET 40/80D does not have it's own keyboard, so needs to support both the Normal / Graphics / Chiclet keyboard, and the Business keyboard.

It's a long story that I am sure I have covered many times before, but these two are not at all compatible. The matricies matrixes matrixs matrixie matricies... wiring, yes the wiring is different. Both keyboards have keys in common, but they appear in different places in the keyboard matrix. They also have a lot of keys not it common and requiring different combinations of shift or not.

Aside: for example, I was trying to add support for the business keyboard to Tut-Tut. That currently supports both directional control using QA and OP as well as the numeric keyboard keyboard 8+2 and 4+6. (although I notice as I write that that I only mentioned QA OP on the info screen, so maybe I can get away with dropping 82 46 ?)

The scancode for 4 on the normal keyboard is 46, so when I see a scancode of 46, I move the player left. But, the scancode for P on the business keyboard is also 46, so I should move right?

There is no easy way to tell programatically what keyboard is being used so you just have to select keys that don't overlap like that do.

Back to the main feature.

The PET sets it's keyboard mapping in the editor ROM, and so needs more ROM sets to support the business keyboard as well. The next ROM is the 27C080, which gives 16 options. However, BASIC 1.0 did not support the business keyboard, and the test ROMs are not keyboard dependent, so do not need to be duplicated. That left a few spaces in the ROM.

Seems a shame to leave unused space. What can I use the space for? I know, I can fit a game into ROM. Cheese and Chive seemed a good choice as it is a great game and also shows off 80 column mode. The prg file is 23K, so that will fit into the 32K ROM space, this is going to be easy.

Spoiler: It wasn't easy.

I had expected it would be similar to the way I load some of the games in the Penultimate Cartridge for the VIC20. Most of the ROM images on there are from cartridges, so are designed to run from ROM, and just need to be mapped into the address space at the appropriate locations. Others were not written as ROM games, so to make things easier, I have a stub program that copies the game into RAM, and then runs it from there.

I can do the same thing on the PET then?

Well, no, there is a slight, but very important difference. Other than 8K from 9000-AFFF which is for options ROMs, the ROM space on the PET is already taken up by BASIC, editor and kernal ROMs, and space for IO and video RAM.

Well, I can just replace those with a dummy kernal ROM that loads the game, it doesn't need BASIC right?

I wrote the kernal loader and assembled the ROM image and tried it out. I got a blank screen. Occasionally a few characters in the middle somewhere, but essentially nothing.

I checked with Misfit (the author of this and other wondrous titles - misfit.itch.io) and was assured that no library routines were used.

Tracing it through, I found the code was actually calling a kernal routine, BS_OUT, write a character to the screen. Misft checked and it was only called from the crt0.asm file added by the compiler, and only called once to change the screen mode when the program starts.

I added a dummy routine in the correct location in my dummy kernal ROM and tried again.

Now I got just a blank screen, no more random characters.

(imagine there was a picture of a blank screen here)

Further trimming of the crt0.asm to remove unnecessary calls to routines that didn't exist followed and then I got a screen.

But that is all it did. It is meant to start writing out the text of the title screen.

I guess this is related to the timer interrupt. I did account for that an set up a basic interrupt handler which should work like the original one did.

What normally happens when an interrupt is triggered is that code execution stops and jumps to address stored at FFFE. This is usually E442, which is in the editor ROM. This stores the registers, then jumps to the address stored in the zero page CINV handler (0090). This can be set to jump to a user routine, or will normally jump back into the editor ROM at E455. Here it does the usual interrupt handler stuff such as scanning the keyboard and updating the jiffy counter. Finally it restores the registers and returns to the code it was running before this started.

I knew that Misfit's code had a user level interrupt handler (set using the 0090 redirector), so I implemented a version of that, but at an address in the fake kernal ROM.

I had bypassed the keyboard scanning and jiffy counter, but forgot that the act of scanning the keyboard included writing the the PIA port B which was necessary to clear the interrupt. Without that, my code was locked in a perpetual interrupt.

.....

Skip a load of testing and dummy programs where I got the interrupt working and incrementing counters on the screen as well as running code. 

.....

In order to try and work out what was going on, I wanted to extend my test program to not just write 1,2,3 etc. to the screen, but to run bits of more useful code. I decided the easiest way to do that was to try to make a ROM version of a one of my games to test out the mechanism and see if I could get a game running from ROM. 

I chose Tut-Tut and modified the source so it would run directly from ROM. That was small enough so that I was able to leave the entire original editor ROM in place. I left out most of the disk and tape routines in the kernal ROM, but implemented the full jump table at the top of the ROM, most of which were set to simply return.

With a bit of tweaking for a few more entry points, I got that running, 

Aside: This worked well enough that I did add it to one of the spare slots in the ROM, however, I'll probably leave it as an easter egg as it doesn't currently support the business keyboard. For two reasons:

1. The issue previously identified of clashing scan codes.
2. The built in editor ROM is for the normal keyboard Mini PET BASIC 4.1

The first could be fixed by modifying the inbuilt scanning routine to use QA OP only, with scan codes for both keyboard types. The second is a problem because bits of the Tut-Tut code (mainly the menus) use the kernal scanning routines, and so would need to be rewritten to use the alternate scanner to work with either keyboard type. 

OK, back to Cheese and Chive again.

Misfit was kind enough to send through the source of Cheese and Chive, so I could rebuild it to run directly from ROM with the new editor and kernal, rather than being copied to RAM as I had previously done.

Great, that's almost working. But all the characters are inverted?

Anyone that has used cc65 will know that string handling can be a little confused. It seems that you spend a lot of time trying to work out what to write in the code so that when it gets mangled by the compiler the right thing will appear on the screen. It's a combination of ASCII being different to C64 character sets, and those being different from PET BASIC 1 and also from PET BASIC 2 and 4. Also the differences between uppercase characters in graphics and text mode. Also the difference between characters you send to the PutCh function vs the numbers you poke to screen RAM. And finally, I think it sometimes randomly sets the higher bits in the character to mess with you.

Misift's code has some workarounds to deal with that, and offsetting the characters by 40 before writing. I found that changing that to C0 made most of it work.

A few more tweaks and the titles were fixed.

But there were still problems in the game part.

Misfit was helping and trying these changes as well. On his system, the same code had problems in different places, he had bad characters on the title screen, but the game was OK.

Further analysis of what was different, came down to lots of weird stuff. I was using V2.18 on Linux, Misfit was using V2.19 on Mac. However, that's not entirely correct as it turns out that a bug listed against 2.19 said 

"NOTE: The programs in release V2.19 report their version as V2.18" 

I had to build direct from the current master instead of release version.

Right, getting there. The versions now matched, but there were still problems.

Misfit made some changes, and reported the menu was now wrong, but the game worked.

When I built it, both worked. Success, but why?

Misfit was using a makefile with ca65 and cc65. I tried with a makefile, and also got the menu is wrong, but game is right.

I normally build from a batch file, using cl65, with the same options

cl65 -t pet -v -C rom.cfg -O -Oi -Os -Cl *.c *.s

Using a batch file (calling cl65 only), and version 2.19 and the latest tweaks, the menu was right and game was right. 

Retesting with the same code, but built from a batch file using ca65 and cc65, the menu was wrong again, just like the makefile. 

At this point, I had code that compiled and worked, so I stopped beating my head against the wall. 

So all sorts of things that shouldn't have made a difference, did. I bet all my other programs won't work now.

All of the pictures above with green characters above are screenshots from the Vice emulator. But will it work on real hardware?  I had been testing various versions throughout, and they had been behaving the same as the emulator, but I had to be sure after all of the silliness we had seen with characters.

Yes, everything working as expected, direct from ROM on real hardware.

Here is Rod Hull from TFW8b testing out the Mini PET 40/80D, including Cheese and Onion below. I can only apologise that it starts with "Yo". I don't know what he was thinking.

Advertisements

As Rod states in the video, the Mini PET 40/80D boards are available here, with Cheese and Chive (and Tut-Tut) in the ROM, ready to go.

https://www.thefuturewas8bit.com/shop/tynemouth-products/minipet4080d.html

This post is an updated version of a post from my Patreon. If you want advance previews of posts like this and behind the scenes progress on new projects, you can follow along and support me on Patreon:

https://www.patreon.com/tynemouthsoftware

The History of the Mini PET

I have been meaning to write up the history of the various versions of Mini PET, so here it is.

It all started a long time ago when I was working on some tools to help repair PET boards. I had built various boards to bypass the onboard ROM and RAM chips, and had been working on something to bypass the onboard display.

That board duplicated the onboard video RAM with some dual port RAM which was scanned by a microcontroller to display the screen on a small 240x320 LCD panel. This gave a 1:1 pixel perfect copy of the PETs 200x320 display, other than an extra 20 pixels top and bottom.

I ended that blog post (http://blog.tynemouthsoftware.co.uk/2016/08/pet-lcd.html) with the following:

One final thought, this is a 6502 CPU, ROM, RAM and a display. Stick in clock, reset and some IO, and you've got yourself an SBC. Add the appropriate ROMs and IO and you've got yourself a mini PET........

Spoiler: It took me a few years, but I got there in the end.

I sold a few of the PET LCD boards, but was not able to get a good source of the LCD modules.

I bought dozens from various supplies and rejected most of them due to scratches or other damage. I kept using the PET LCD, and worked on a few variations, including one with composite video output.

I was looking at using this for testing machines with faulty displays, and also added the option to drive PET monitors. The idea being that it could be used to add a 40 column display to an 80 column machine (but not to add 80 column to a 40 column machine at this stage)

It looks like I was borrowing the composite video mixer output stage of a Minstrel 3 for some reason

It took a lot of writing and rewriting the code to get the timing right, one instruction out is enough to mess up the start point of a line.

I eventually got that to the point where it was generating a clean stable display, and decided to see if I could actually make a Mini PET.

And here is Mini PET version 1.00.

A key to this being possible is the W65C series of chips from WDC. These include versions of the 6502, 6520 and 6522 needed to make a PET entirely from new parts (which continues to be the case other than the dual port video RAM was has unfortunately now been discontinued)

It needed a few tweaks here and there, but it wasn't long before it could play invaders.

It was all coming together quite nicely.

And with a few more tweaks, the first production board were ready.

This board could either be used stand alone, or fitted into the case of a Commodore PET, with a separate board to generate 9V DC from the PETs internal power supply. 

The three rear connectors lined up with original PET board edge connectors, but the board was only wide enough to pick up on one rear mounting screw.

The size was set by the width of the PET replacement keyboard I had already designed, which itself was the same width as the PET chicklet keyboard.

When ordering the second batch of boards, I got half white as before, and half with a green solder mask. That made it easier to differentiate between the stand alone (white) boards, and the PET replacement (green) versions of the kit. We had been using Mini PET "Kit A" for the stand alone kits and "Kit B" for the PET replacement ones, but the colours were easier.

The first batch of green boards had been the same design as the white ones, but for the second batch of boards, I made some changes to better suit being fitted into the PET case. 

The green board was widened to pick up the second rear screw hole, and the power board was integrated. 

The central section with the chips in remained unchanged, just the sections around the sides were different. A second datasette port was added on the side to match later PET boards.

At one point, I updated the design of the internal board to use jumpers rather than DIP switches, but 1) if was more trouble to pack the kits with separate pin headers and jumpers, and 2) it was more trouble to solder them in. I went back to DIP switches for the full run.

The stand alone version also got some upgrades, including the deluxe keyboard version.

The next change was to add 80 column support. I had initially ruled that out as it required so much extra circuitry in the 80 column PETs. However, it turned out most of that was due to the video RAM they had available not being fast enough and having to alternate between odd and even banks to keep up.  That also meant that switching to 40 column mode involved a significant amount of rewiring. 

Coming back to the project after a while I realised I didn't have to do all that since I was using modern RAM that was more than fast enough. In the end, I was able to add switchable 40 and 80 column support with a few slight modifications.

The first version of the 40/80 was the same format as the previous models.

At the same time (end of 2020 / early 2021), there was also an internal through hole kit version of the 40/80.

At this point, I had shut down my Tindie store and was very much reliant on TFW8b to sell these kits, but they still had stocks of the standard Mini PET kits, so these versions were never sold. They did however express an interest in a pre-assembled version of that board, so I designed one. 

The WDC 65xx chips were available in PLCC, as was the IDT 7132 dual port video RAM chip, so I went with those. I left the two ROM chips as through hole to simplify things during production. 

Since there was space on the board, I wondered if I could fit an SD2PET on there as well, hence the name, the Mini PET 40/80D, in the same style as the PET 80296D and Commodore 128D, both of which had built in disk drives.

TFW8b didn't like the location of the SD card slot, so it was moved to the side where the second datasette port had been. I wasn't sure if that would work, it meant either running the SD card SPI bus from one side of the board to the other, or running the IEEE-488 bus from top left to button right. Neither was ideal, but the SPI bus and other SD card signals required fewer wires, so I went with that and it worked out fine.

That was put on hold a few times due to economics, chip shortages etc. The stand alone 40/80 was also progressing, waiting for an opportunity to make kits again. In that time, I worked on the ROMs, adding a built in file browser and expanding the built in self test.

We talked about various options, and a new improved Mini PET 40/80 spec was conceived, with soft power on, 9 way D monitor connector, both datasette powers, 40/80 switch, dedicated NMI button to launch the new file browser etc.

My first attempt added the extra buttons above the numeric keypad, but I was not happy with this as it spaced the buttons out a little too much.

For the final board, I went back to the spacing of the original deluxe keyboard, and added the new switches to the side instead.

It was at this point that the PCB manufacturers messed up with a batch of boards and so the Mini PET 40/80 Stealth edition was born.

The actual production run did have silkscreen, and a very nice spiral bound manual, the Mini PET 40/80 was complete.

The Mini PET 40/80 was launched with some arty shots from The Future Was 8 bit.

That seemed to be well received, so the 40/80D was back on the cards. Another spin of the board followed, as I wanted to add back the second datasette port (although after the fun I had with the fast loaders on port 2, maybe I shouldn't have bothered).

The final change was adding the second datasette port on the bottom edge.

This board is different to all the others shown before. This one is factory assembled, the first of a trial batch. Just to the left of the power connector you can see the first fiducial I ever put on a PCB. It looks rather nice coming out of the factory as a complete unit, just needing the micrcontrollers programmed and the ROM chips installed. 

As with the previous "B" kits, the "D" board is designed to fit into a PET case. I usually test with the extremes of the range, starting with an original 2001 with the 9" monitor and built in datasette.

The 2001s have the 5 pin version of the power supply connector. The board is designed to accept either this or the 9 pin version used in other PETs. The prototype run of factory boards had black power connectors where the pins were a bit too short, you can see that 5 pin connector is just hanging on, the production run have the correct taller white connectors I had originally specified.

The internal datasette drive on the 2001 is plugged into port 2. So you can still load from tape if you want to.

At the other end of the range, here is the board fitted into one of the later CBM models with the 12" monitor. (everything apart from the 8032-SK and 8096-SK, the keyboard and power supply cables doesn't reach, so it would require a bit of fiddling - consider then as not supported).

There are a number of ROM versions available, by default it boots to Mini PET BASIC 4.1 and 32K of RAM.

As before these can drive a PET with a 9" or 12" monitor with 40 or 80 columns.

You can go 80 column even if the PET was originally only 40 column

Yes, you can even run 80 columns on the 9" monitor of  a PET 2001 (here showing the built in self test). 

There are connectors on the right for 9V DC power and composite video out, which can be used for testing.

You can use a normal / graphics keyboard, or the business keyboard (with the smaller numeric keypad and numbers on the top row of keys). Real PET ones, or replacements such as the ones I used to make, or the Cherry MX switch versions from 8-bit Guy's mate (https://texelec.com/product/petskey/) or these from Steve Gray (http://www.6502.org/users/sjgray/projects/mxkeyboards/index.html).

Although you can do that, the Mini PET 40/80 with the built in keyboard is a better option for bench use.

So there is the potted history of the Mini PET, Mini PET 40/80 and Mini PET 40/80D. If you fancy one of your own, the latest incarnations are available from The Future Was 8 bit here:

https://www.thefuturewas8bit.com/shop/tynemouth-products.html

PCB only and PCB + programmed parts only versions of the earlier boards and separate keyboards are available from my SellMyRetro store (UK only - sorry).

https://www.sellmyretro.com/store/tynemouth-software

This post is an expanded and updated version of several posts from my Patreon. If you want advance previews of posts like this and behind the scenes progress on new projects, you can follow along and support me on Patreon:

https://www.patreon.com/tynemouthsoftware