Jump to content
IGNORED

TI-99/4A with a Pipistrello FPGA board


speccery

Recommended Posts

 

 

BTW, a Geneve is a very different beast than the TI-99/4A, with the advanced 9995 processor, mapped memory etc.

 

 

I've played with the TMS9995 processors on a breadboard (with FPGA support) and on a single-board computer. The '95 is much faster thanks to internal architecture improvements, but the instruction set is basically the same, with a couple of additional instructions. Since this whole thread is essentially about having more memory and thus paging, that step is in a sense already done, although I don't know how the paging system on the Geneve looks like. I can't be too different though.

 

I also have two TMS99105 chips waiting, it would be interesting to hook one of them up to an FPGA otherwise acting as a TI-99/4A. Those run at more than twice the speed of the '95, but are still from the same era and true TI silicon.

Edited by speccery
Link to comment
Share on other sites

Real life has kept me busy this week. I unfortunately injured a little my leg last week, to the point that I've got a cast on for a while now. Not great as I also need to travel for work the entire next week.... And when I can't do sports it feels like my brain is working at half the speed. Oh well.

I don't think I'll have a lot time to do much in the coming week, but if I do I think I need to get some TI assembly programming going. On that note, I'd like to ask you programmers what toolchains do you use for TI cross assembly development?

I have done a lot of assembly programming on many different processors, but not so much for the TMS9900. I have only done TMS9995 assembly programming so far for the breadboard etc, so not on the TI-99/4A platform. I've used the asm994a and as99 (a unix style cross assembler) to make ROM firmware. I have to say that I don't really like asm994a, I prefer command line tools and makefiles to automate the workflow.

Having said that, I think it would make sense for me to write the software such as hardware device drivers using toolchains that are commonly used by the community, so that if I come up with something useful that work could easily be used by others. The choice of toolchain would mostly amount to the assembler directives and perhaps the way the assembler handles arithmetic expressions; the code itself would obviously not really change regardless of the assembler.

Opinions? This forum thread is probably not the best for this question...

Link to comment
Share on other sites

I use Notepad++ and Asm994a for my fbForth 2.0 development. Over the past five years, I have run into only two problems I can remember, viz., too many labels (happened around 2800 labels, which forced me to write better code) and labels that collided with the limited and undocumented macro commands (IF, THEN, ELSE, ...).

 

...lee

  • Like 1
Link to comment
Share on other sites

I use Notepad++ and Asm994a for my fbForth 2.0 development. Over the past five years, I have run into only two problems I can remember, viz., too many labels (happened around 2800 labels, which forced me to write better code) and labels that collided with the limited and undocumented macro commands (IF, THEN, ELSE, ...).

 

...lee

 

Hi Lee, thanks for sharing your experience. Now I have to also take a deeper look at your project, which looks like a great one in its own right!

Before jumping over to assembly programming I actually used Forth for a while to learn programming (on my ZX Spectrum back in the day). I've done two Forth implementations myself, one for Amiga 500 and another one for one of my self made single-board computers (based on the MC68HC11 processor). As you probably know, there are many FPGA implementations of Forth processors (or stack machine processors which pretty much run Forth as their machine language). Hardware implementations of stack machines on FPGAs are small and efficient, and typically run at great speeds, as the memories for return and parameter stacks can be stored on-chip and accessed concurrently. I haven't done any work on that field myself, but this too would be another interesting avenue. The Gameduino VGA board for the Arduino boards is FPGA based and has a simple stack machine as a co-processor. That stuff is open source and easy to integrate into other designs - including this FPGA project...

 

Erik

  • Like 1
Link to comment
Share on other sites

 

Thanks for sharing your experiences. Gotta like your nickname "Asmusr"!

 

Erik

 

SLC "rasmus",1 :)

 

I'm thrilled to see more people interested in TMS9900 assembler. It seems like there's only a handful of active developers left.

 

Regarding hardware and FPGAs: We could really need an open source replacement for the nanoPEB that's no longer produced. Would be a cool project to participate in.

  • Like 3
Link to comment
Share on other sites

OK, you win. :)

 

Funnily, during an exercise session for my students, I used the SLA command in a program. This led to some surprise, because the MIPS platform that we teach only has a SLL operation. This seemed to have been assembler from my subconscious.

 

(Thinking longer about that, SLL makes more sense.)

Link to comment
Share on other sites

 

SLC "rasmus",1 :)

 

I'm thrilled to see more people interested in TMS9900 assembler. It seems like there's only a handful of active developers left.

 

Regarding hardware and FPGAs: We could really need an open source replacement for the nanoPEB that's no longer produced. Would be a cool project to participate in.

 

 

That's a nice way to come up with an alias :thumbsup: - why didn't I think about that... :)

 

I did a simple modification to the ascart.asm example (added register display in hex), assembled that with xas99.py. I used classic99 to debug it (yes I did manage to make a bug in just a few lines: MOV R3,4 is not quite the same as LI R3,4 which I wanted - no warnings, I'd prefer that the R prefix is required and not optional for registers) and got it to run both on classic and on the actual hardware using my USB serial loader to the FPGA. This actually marks the first assembly program I've written (modified in this case) to run on an actual TI! :D I don't dare to count how many years it was in between from owning my first TI to this day...

 

I don't have an issue in open sourcing my code, I think it would be fun to get some collaboration going. I feel I've used so many open source projects that it is about time to contribute something back. But a development hardware platform would be needed. What I am using (the Pipistrello + buffer board + wires + connector) is great but a tad expensive and a design based on this FPGA would be hard to manufacture. At the prototyping level having so many jumper wires from the side connector to the FPGA board makes it a little hard to construct and move the system around.

 

I have been thinking about creating another iteration of my SD processor board, replacing the CPLD with an FPGA, adding level shifters, upgrading the micro controller, adding a RAM chip. It would become quite a different board from my previous board. Anyway that would effectively become a nanoPEB on steroids. Probably for the first iteration of such a board I would shy away from SDRAM and just go with regular SRAM - the board would be complex enough without having to deal with SDRAM signals.

 

Erik

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...

This week was a travel week... But I got home and had a little time to work on the TI.

I added the SPI interface to the FPGA, this was a straight port of my previous VHDL SPI port code. I have no test code for it yet. The SPI connects to the micro SD slot on the board.

 

But I did spend some time in writing TMS9900 assembly code, and wrote a simple hex dumper for the TI. It is also a simple testbed for assembly coding, having code to write to the screen and reading the keyboard (just to change the dump address). I posted a picture of that below (actually not yet since I don't know how to do that and don't have time to find out right now). I noticed that unfortunately still there are probably some problems with the memory interface - placing the CPU workspace into external RAM yields strange behavior. Running machine code from external RAM while keeping CPU workspace in internal 16-bit scratchpad works (or seems to work).

 

My next plan is to port my existing code to read data from FAT16 formatted SD card to the TI, and to implement some memory test code to understand what might be wrong with the memory interface.

  • Like 1
Link to comment
Share on other sites

I posted another update to hackaday. Advances come in small steps. I did get the external RAM now fully working with my code, so I am starting to build up some confidence that the memory interface is finally reliable. I had great fun working on the memory dumper app in TMS9900 assembly. As part of the very small improvements it now copies the smaller font definitions from GROM to VDP pattern tables, making the hex dump much more readable.

  • Like 2
Link to comment
Share on other sites

Some questions.

 

This pertains to what you are doing specifically, not what can be done.

 

As I think I understand it, the memory expansion is 64mb but it's mostly for storing cartridge images? So the ti still gets the standard 32k ram, the rest of the 64mb is for images?

 

And better video output and apparent cpu speeds (only because much of the processing happens on your board, not that the tms9900 is replaced or anything)

 

That's what I gather and it awesome. And that is your project summed up?

 

 

Now, for what might be possible?

High speed high capacity storage maybe?

A way to add more than 32k of ram?

 

I'm really attempting to understand the full scope of this project.

  • Like 1
Link to comment
Share on other sites

Some questions.

 

This pertains to what you are doing specifically, not what can be done.

 

As I think I understand it, the memory expansion is 64mb but it's mostly for storing cartridge images? So the ti still gets the standard 32k ram, the rest of the 64mb is for images?

 

And better video output and apparent cpu speeds (only because much of the processing happens on your board, not that the tms9900 is replaced or anything)

 

That's what I gather and it awesome. And that is your project summed up?

This probably is a good moment to summarize the project status. As a starter I'd just like to point out that it is a hobby project, so I did not really set some specific goals for myself, other than having fun with the TI, expanding it to a point that makes my configuration (the bare console) useful (as in having fun) - and hopefully resulting in something that can be easily replicated by others. That last step probably in practice means designing a custom board.

 

As of today, the following functionalities are implemented:

  • SDRAM interface, allowing the entire 64MB of memory to be accessed by the TI.
  • Memory paging unit, which breaks the processor's 64K address space to 4K pages. The location of each page in the 64MB memory can be independently set. In practice this relates to the 32K memory expansion portion of the address space visible to the CPU. But the entire 64MB is accessible. This unit is compatible with the SAMS extension system, with the exception that CRU support is not there yet and thus the banking registers are always visible in the processor's address space. Also the way in which memory paging is enabled is currently non-standard.
  • Accesses to the cartridge ROM area (TI's address range 6000-7FFF, 8 kilobytes) are remapped to SDRAM. There is support for 74LS378 style non-inverted banking of the cartridge ROM area. Extended Basic uses this type of banking too. There are 128 banks overall, thus 1 MB of memory can be reached through the cartridge ROM window. In the SDRAM that area is from 16MB to 17MB. Note that this area is not specifically reserved for cartridge ROM, it just so happens that accesses to cartridge ROM get combined with the cartridge ROM page number and an offset of 16M is added. That same memory area can be also accessed through the memory paging unit, using addresses that belong to the 32K memory extension.
  • The FPGA implements the GROMs of the extended basic cartridge internally. In other words, there is a 4*6K=24K GROM compatible memory, currently loaded with the extended basic GROM contents.
  • There is a memory mapped SPI port, connected to the micro SD card on the pipistrello board. Thus support for SD cards (i.e. mass memory) is there, once I get around writing some software for the TI. This is still untested, but the SPI port design is mostly what I've used earlier in other projects. The port runs at 12MHz, which may be too much for some SD cards (I have earlier used the port at 6MHz).
  • Finally there is a memory access state machine, connected to a USB port serial channel. This allows access to the 64MB SDRAM from a PC. The PC can read and write the RAM concurrently to the TI itself using the memory. I have mostly used this capability so far to load extended Basic ROMs, game ROMs or my own memory dumper ROM from memory location 16M onwards, making them look like the corresponding cartridge would have been plugged in.
  • A bunch of debug registers, allowing the TI read from certain memory locations the status of the SDRAM (to for example find out that maximum SDRAM access cycles are about 28 cycles long at 100MHz).
Currently that's it. There is no speed up for anything yet. Speedup could be realized by also implementing the console GROMs in the FPGA, and then removing the original GROM chips from the console. The internal GROMs determine the speed of GROM accesses by delaying the CPU, making them horribly slow. The FPGA GROMs operate immediately, there is no need for any wait states.

 

There is no video circuitry implemented, although that could be done as the Pipistrello has a HDMI output port, and there are examples how to drive the HDMI port, so that could be done.

 

That's the overview. The short answer is that the entire 64MB of memory is available for programs.

 

 

Now, for what might be possible?

High speed high capacity storage maybe?

A way to add more than 32k of ram?

 

I'm really attempting to understand the full scope of this project.

I hope the above lengthy explanation of current specs answers the memory question. Note that to go over 32K of RAM, the programs need to support that specifically by modifying the paging registers as the program runs. You could for example keep 28K (7 pages) in fixed locations in the 64MB memory, and use the remaining 4K as a window to the rest of the memory. You could just change the page register for that 4K area as the program runs.

 

Already with the current hardware configuration a lot can be done. I think I want to enable the SD card support next, which means that I'll probably be spending time writing software rather than VHDL code for the FPGA. It is almost the case that the sky is the limit here, the FPGA has so much capacity left that it could implement graphics circuitry, coprocessors for various tasks, etc. Plus the entire circuitry of a TI-99/4A a few times over.

  • Like 1
Link to comment
Share on other sites

One note, although TI only used 6K for each of their GROMs, later GPL programmers often used the entire 8K identified in the map for each GROM. Without this capability, interesting modules like XB 2.7, XB3, SEB, and RXB won't work.

Thank you for that comment. Actually I want to move the GROM contents over to the SDRAM too, it is overkill to use the FPGA on-chip block RAM for this purpose. So my plan is to set aside a region of SDRAM and have the GROM accesses use that region, similarly to what is done with the cartridge ROMs. Once that is done there is abundant memory available, so I'll make the GROM's 8K each. I wanted to keep them 6K as long as they're implemented with the FPGA block RAM to minimize block RAM use. It is not so important for the pipistrello board as it has a big FPGA, but once this project is moved to a dedicated board it is likely the FPGA will be much smaller and then this would have become important.

 

A stupid question: where can I get the ROM images for the modules you listed? I'd like to try them out. Actually now that I think about it, XB 2.7 is included with classic99 so that one I probably have already.

Link to comment
Share on other sites

Thank you ever so kindly. Clear, as concise as can be and amazingly understandable. This alone is going to push me further in to development and coding. You're a wonderful inspiration. Great project. I hope to be able to replicate it myself one day.

 

Thank you for those words :) motivation works both ways!

I really want to make this something that others can replicate and hopefully find useful. The easiest way would be to make an adapter board for the pipistrello, but it would be cooler and cheaper if it was a bespoke board.

  • Like 1
Link to comment
Share on other sites

Thank you for that comment. Actually I want to move the GROM contents over to the SDRAM too, it is overkill to use the FPGA on-chip block RAM for this purpose. So my plan is to set aside a region of SDRAM and have the GROM accesses use that region, similarly to what is done with the cartridge ROMs. Once that is done there is abundant memory available, so I'll make the GROM's 8K each. I wanted to keep them 6K as long as they're implemented with the FPGA block RAM to minimize block RAM use. It is not so important for the pipistrello board as it has a big FPGA, but once this project is moved to a dedicated board it is likely the FPGA will be much smaller and then this would have become important.

 

A stupid question: where can I get the ROM images for the modules you listed? I'd like to try them out. Actually now that I think about it, XB 2.7 is included with classic99 so that one I probably have already.

 

 

They are all in the forums here.. http://atariage.com/forums/topic/243766-bin-repository-images-for-burning-cartridges/

has links to most.. also the mess cartridge archive on whtech for the rest

ftp://ftp.whtech.com/Cartridges/MAME/

Edited by arcadeshopper
  • Like 1
Link to comment
Share on other sites

So I then went exactly to the opposite direction than I thought - no software development today - instead VHDL development...

I looked again at the cool FlashROM99 project and realized that I have been stupid. Facepalm time.

What the FlashROM99 actually is?

  • Banked RAM in the cartridge port area. Check.
  • Needs 32K memory extension for some binaries. Check.
  • A capability to load raw binaries to the banked cartridge RAM. Check (with my USB loader).

What else? Nothing. Nothing. I basically have had this capability for something like two weeks without realizing it. Aaarrgh!!!

Well I guess it is better to discover this later rather than never... So I downloaded the binaries and tested them. All the ones I tested worked :)

 

Ti Scramble running from the Pipistrello memory expansion

 

Sports running from the Pipistrello memory expansion

  • Like 2
Link to comment
Share on other sites

And then I realized that one of the binaries was the SAMS memory test V4.0. It was time to become fully SAMS compatible. So I added one more wire between the side connector and the FPGA (CRUCLK* signal) and modified the FPGA in three ways:

  1. Page register visibility controlled by CRU bit 1E00 - same as Super AMS
  2. Paging enable controlled by CRU bit 1E01 - same as Super AMS
  3. A non-standard CRU bit 1E03 when set enables paging of the entire 64MB memory range (16bit page numbers). By default this is reset, reducing the paged area to 1 megabyte with byte sized page numbers, but this is required for Super AMS compatibility.

And now the design passes the memory test :-D :

Super AMS memory test

  • Like 6
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...