Close

40 column text mode and 256K SAMS memory added

A project log for RC2016/99: TI-99/4A clone using TMS99105 CPU

Retrochallenge 2016/10 entry and winner: try to build a TI-99/4A clone using a TMS99105 CPU and an FPGA. In a month...

erik-piehlErik Piehl 11/15/2016 at 19:360 Comments

Sometimes I just feel stupid:

I had added support for 256K of SAMS compatible memory extension (SAMS was a memory expansion standard for the TI-99/4A) largely using VHDL from my earlier FPGA project, but the memory test program just would not work (AMSTEST4). The scary part was that once I ran that program, the screen just went weird. The colours were bogus, and there was some misalignment on the text that was written. Basically it all seemed wrong, I was doubting FPGA routing and timing issues.

I did not have time to work on this and during that time I realised, that AMSTEST4 was the very first program I run on my TMS99105 system to use 40 column mode. My video processor implementation of the TMS9918 does not support that. But instead of completely not working, it display the text in 32 column mode, which made everything look funny. I got to work.

I was again surprised how little effort it took to add support for 40 column mode. There effectively are only three changes in the VHDL code:

That was all there was to it. Below is a picture of it working (incidentally showing that SAMS memory test passes now too, more about that after the picture):

So there it is in all its 40 column glory. If you wonder about the blue bar on the right - that's there due to left over data in the line buffer. The previous picture is basically the boot up screen below (well there is a menu in between but same stuff). The previous pictures are in 32 column mode, and 32 times 8 is 256 pixels i.e. the full TMS9918 width, but going to 40 column mode means 40*6 equalling 240 pixels, so there are 16 fewer pixels. Since the 40 column mode does not update the line buffer (used for VGA scan doubling and sprites), the previous contents are there. In text mode the hardware should turn on horizontal blanking for those last 16 pixels, but at least the picture shows the quirk and proves we have the FPGA at work.

Speaking of 16-pixels, I also added a 16 pixel offset vertically, to be able to see the topmost line well. This offset was much harder to add than the text mode: it took several attempts, while text mode worked right the very first time.

The final problem I had earlier, the SAMS memory test not working, was something really stupid: the memory paging actually worked already, but the test application seems to check the lower bytes of page number registers too. The SAMS extension to my understanding assumes that page numbers are stored in every other byte from address >4000 onwards: >4002, >4004, >4006 up to >400E. This was done due to the 16-bit nature of the TI-99/4A, even if the individual page registers are only 8-bits wide. As the external bus of the TI-99/4A was 8 bits wide and it could not do byte proper byte addressing, the registers were spaced out so that only every other byte was used. Even addresses are the ones where software should write page values, and reading from them yields the same values again, but the odd values could be ignored. That's what I thought, but the test program needs the hardware to replicate (during reads) the register values in the odd address too - the same behaviour as with the original TI-99/4A. Fair enough, and now it works.

Discussions