Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by speccery

  1. 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
  2. From the album: TI99FPGA

    Pipistrello FPGA board mess of wires interconnect to the side port of the TI-99/4A.

    © Erik Piehl

  3. From the album: TI99FPGA

    Super AMS Memory tester first successful run on the pipistrello FPGA based memory extension.

    © Erik Piehl

  4. 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.
  5. 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.
  6. 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. 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.
  7. 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.
  8. 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.
  9. That's a nice way to come up with an alias - 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! 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
  10. 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
  11. Thanks for sharing your experiences. Gotta like your nickname "Asmusr"! Erik
  12. Thanks a lot for the pointer. I just cloned the repository and it seems to be packed with great stuff!
  13. 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...
  14. 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.
  15. Yes, so true. Unfortunately not possible except by modding the console itself or by moving the whole thing to an FPGA or by redesigning otherwise the motherboard. In an FPGA implementation all memory would probably would be of full speed and accessed as the 16-bit memory. And at much higher clock speed.
  16. Sounds cool! What development environment are you using? Assembly?
  17. I haven't checked the specs of the Geneve closely, but the short answer is yes. Once somebody builds the standard TI-99/4A into an FPGA, going to a Geneve from there would not be hard
  18. Thanks. I am curious - what would be the role of the TI in your planned setup? As it so happens, the Pipistrello board does have a stereo output jack. It is a very simple setup hardware wise, relying on the FPGA on doing very high speed sigma delta modulation for digital to analog conversion. That's a fancy way of saying there is a capacitor and resistor connected to a pin of the FPGA and the audio output jack. By toggling the output pin in a suitable way a DA conversion can be done, at a quality that is probably very nice at least on retrocomputer standards. It would be straightforward to setup some memory aside for audio sample buffers, and have the FGPA pull out samples and output them autonomously. The TI could write the waveforms to the sample buffers and control the whole thing. I don't know if this is something of interest to you in your application. A quick general comment about the possibilities here: the FPGA on the Pipistrello board is pretty huge in terms of its logic and memory capacity. My rough estimate is that it could implement all of the circuitry in the console probably four to five times, maybe more. I implemented earlier an enhanced ZX Spectrum on a LX9 FPGA (which is maybe one quarter of the capacity of the LX45 FGPA on the Pipistrello). That implementation took about 40% of the capacity of that FPGA (including the Z80 CPU as a soft core). I also ran on the same board the Scramble coin op game (the circuit has two Z80 cores and a whole bunch of other circuitry, occupying something like 75% of the FPGA if I remember properly). Right now all the circuitry I've so far coded takes about 3% of the capacity of the FPGA on the Pipistrello. So there is a LOT of room for logic and circuitry here. Having said that, my intention is to keep the circuitry within the realm of what would fit on the LX9 chip, since that chip is available in a more "home builder" friendly 144 pin quad flat pack package, and it would not be that hard to make a custom expansion board based on that chip.
  19. I guess there is a hardware and software answer to your question about program RAM. This may be obvious: On the hardware side the TMS9900 microprocessor has a 16-bit address space. As such it can directly only access 64K memory at any one time. The way to go beyond 64K is to use memory paging. The 64K address space is divided into 4K pages, and the programmer can choose where in the 64 megabyte RAM space each 4K page actually is. So the program can change what the processor sees in each 4k page slot. However, the TI-99/4A is designed in such a way that 32K i.e. half of the address space is already reserved and not available for memory expansion. To be more precise the hardware in the console already occupies 16K which is not available to be reused or paged with external hardware. Of the remaining 48K address space the design convention is that 32K is for memory expansion, 8K for cartridge port and 8K for device driver ROMs. The cartridge address space and device driver ROM space is actually visible on the expansion bus and those areas could be paged, but that would work somewhat against the usual conventions and would not work well with existing software. Which brings us to software: in order to use any memory beyond the regular 32K, one has to resort to some sort of paging, which means dedicated software support for a given paging system. That's why I am trying to follow the SAMS spec, in order to have something that would be recognised by existing software. Thus with my FPGA setup a program can use 64 megs as program RAM, but the program(s) needs to be aware of that setup and use the paging unit accordingly to gain access to that memory. In practice the 64 megs is so much compared to the TI's speed, that even with the maximum theoretical speed it would take a long time for the CPU to just touch each memory location. The external bus accesses memory at 1MHz, so in ideal conditions it would take about one minute to touch the memory just once. In practice the CPU would need to do a lot other things too, so we would be talking about many minutes. I hope that makes sense - and answers your question...
  20. I live in Finland. In Finnish the word "Pipi" means sick or ill and I found it very amusing in the beginning - I suppose I got used to that since...
  • Create New...