Jump to content
IGNORED

Erik's ET-PEB


speccery

Recommended Posts

A quick update here: I got notification from the PCB manufacturer that the PCBs are on the way to me from China. I suppose that will take a while, but I am anxiously waiting for them. I also started to work a little on the CPLD design, it is not completely done yet, but it starts to seem that I may be able to fit what I need onto the chip although it will be a close call. The primary job of the CPLD will be to arbitrate between memory accesses from the TMS9900 and the ARM microcontroller, as well as supporting SAMS memory expansion.

 

I've now put in logic to support for access to RAM from the CPU, DMA loading for the ARM (although not entirely complete), DSR paging logic for the disk support, CRU bits for disk controller, paging enable and page register access. I still lack the actual paging step and a few bits and bobs, but the design is now using "only" 99 out of the 144 macrocells, so I have still some room to work with. I just hope that once the chip truly starts to become full nothing awful happens. The paging implementation needs about 20 more macrocells, so I should have still some margin.

 

Once I get the logic done I need to do so simulation runs on It to verify the design, hopefully at that stage nothing surprising will surface. The good thing in CPLD design it seems that it is pretty easy to imagine how many macrocells a given function might take. I actually have spotted some design errors simply by looking at the amount of logic created by the synthesis tools, sometimes chip usage did not increase like I anticipated, and the reason was simply a bug in the design making the tools completely omit certain elements...

  • Like 7
Link to comment
Share on other sites

I think functionally the CPLD design (first version) is now complete. I hit a routing error, there is not enough routing capacity for CRUIN pin (used by the CPU to read CRU, i.e. I/O devices) in the CPLD. However, I have a few spare pins, and routing CRUIN to one of them solved the routing problem. If the design works like this, it just needs a patch wire to fix this issue.

 

Overall I have done no simulation yet and have no idea if this CPLD design works, but it is now pretty much feature complete. Theoretically it should work, the design takes 115 macrocells now out of the 144, so there is some room to fool around. Since the CPLD is very full and clearly routing is a problem, I hope the simulation (and testing later) does not reveal too many bugs.

 

I have implemented:

  • The ability for the ARM processor to both read and write the entire 512K SRAM
  • Support for SAMS compatible paging for 256K region of the SRAM (by far the most complex part of the design - it is a miracle if it works like this, I am pretty sure testing will reveal interesting things)
  • Support for standard 32K RAM expansion (if SAMS mode turned off, which it is by default)
  • Arbitration between the ARM and TMS9900 running at high speed, allowing the TMS9900 to access the RAM at full speed, while still enabling the ARM to transparently access the memory. For sure this thing requires testing!
  • CRU bits at CRU space locations 1100, 1E00 and 1E02 to support disk DSR driver memory, SAMS page register access and enabling of paging

Those are the enabling features to everything else. If these actually work, a lot of interesting features can be implemented. It probably is possible to add support for ROM cartridges, at least 8K ROMs, not sure if cartridge paging will fit. GROM support will not into the CPLD, but it may be possible to add a feature where the CPLD would halt the TMS9900 (via READY line) when it is accessing GROM ports, and to have the ARM then emulate GROM functionality and then release the CPU. Would be nice to have, but may be hard to do in practice.

 

At any rate the ARM controls external interrupt lines to the TMS9900 (both normal interrupts and the LOAD# for NMI), potentially enabling interesting features.

 

The disk DSR functionality plan is very simple: the ARM will continuously monitor certain memory locations, which the disk DSR routine on the TMS9900 side would write. It would then act accordingly, reading or writing to the SD card or flash memory, and transferring results to/from the RAM.

Edited by speccery
  • Like 4
Link to comment
Share on other sites

I've now had some time to work on the first prototype. I posted on facebook the picture of the PCB, so probably many of you have already seen that. Here a pictures of the first assembled board being debugged. This is the first time I've used easybug, and it is a very useful tool for this type of thing.

 

When I got the PCBs I was very excited to start assembling and I actually had some time this weekend to work on the boards. Alas, as I had just returned from Tokyo, I was too tired to do a good job of assembly. It took me something like 3 to 4 hours to put the board together, another couple hours to correct all the many mistakes I did. Yes, I did burn the first MCU and CPLD due to stupid mistakes. I made too many mistakes I care to admit - I've used these parts in the past and I don't remember it been this hard. Certainly this is the first time I've burned chips... Apparently it is possible to add pin constraint file to Xilinx tools in a way where the fitter does not respect pin assignments - ouch!

 

I was getting very frustrated when initially it seems that nothing worked and that for every step forward I was taking two steps back, but this evening I've made some good progress without too many steps back, so its getting to be fun again.

 

But then to the good stuff - my TI-99/4A is still alive, and I have a reasonable amount of functionality tested, although there is a ton of stuff to work on still:

 

  • The ARM micro controller (MCU) can access the SD card reliably and read files off FAT file system.
  • USB serial port to my Mac works flawlessly, which is great for debugging. I can communicate with a simple shell running on the MCU and enter debug commands.
  • Using easybug I can access the 32K SRAM (SAMS support completely untested yet) and write and read bytes from it. Writing and reading manually bytes works, but the memory interface is not fully stable yet. If I insert extended basic, it detects the 32K memory expansion, but entering a basic program and listing it gives me garbage, so there is work to be done here.
  • The MCU can write data to the CPLD and the TI can read it.
  • The MCU can write data to the SRAM and the TI can read those bytes.
  • The MCU cannot reliably read data from the SRAM. Sometimes it works, sometimes it doesn't. When it does work I can observe the same data as the TI, which is good.
  • The TI can read and write CRU bits control bits reliably as far as I can tell. I have the CRU bits 1100 and 1E00 controlling external LEDs, and they seem to work robustly.
  • I2C interface from the MCU works.

In short, it seems now all tested components so far are alive and work. But they do not perfectly together which is not surprising. The CPLD design needs fine-tuning. With some debug stuff in the CPLD in addition to actual functionality I am now using 136 of the 144 macrocells, so the CPLD is 95% loaded. It does contain SAMS memory controller. I have simulated it under the development tools and it seems to work - and of that I am very happy about - but of course that has to be test and it can only be verified once the more basic memory functionality works. The page table entries are stored in external RAM, so each memory access by the TI actually creates two memory operations, one to read page number and another to read the actual data. This works fine in simulation, but since that I've uncovered and fixed other bugs when testing with actual hardware.

 

ET-PEB first prototype being tested and debugged - side view

Above the colourful cable is the JTAG configuration cable going to the XC95144XL CPLD. It is possible to reconfigure the CPLD on the fly while running Easybug - that saves time. The black wire in front is the USB cable going to my Mac.

ET-PEB - top view

Below the SD Card slot can be seen.

IMG 7447

Edited by speccery
  • Like 8
Link to comment
Share on other sites

After much debugging, I am seeing some signs of life.

I can now load files from the SD card and write them to the SRAM. This is done by the ARM MCU. Verification still sometimes fails (i.e. when the ARM is verifying against a loaded file), but in those instances so far my analysis indicates that the bug is in reading from SRAM. In other words, a second read from the same location yields the expected value, meaning that the write has succeeded. I am testing with a 512K test file spanning the entire RAM.

 

Next I need to check what happens on the side of the TMS9900.

 

REQUEST FOR AN EXECUTABLE: could someone post me an executable binary object I could load to extended memory and launch with Easybug? So I need something that produces visible output on screen, and can be loaded to 0x2000..0x3FFF or to the range 0xA000 .. 0xFFFF, and then started with easybug's E command. The actual address does not matter, as long as it is in extended memory. This must be a raw binary file, no TI file headers, as the ARM code is just reading it off the SD card FAT32 file system and dumping it to memory. I have several programs of my own, but none of them runs from extended memory, they all run from cartridge memory. I could recompile and link etc, but it would be faster and easier to have something that already exists. Thanks in advance! :)

 

Debugging on going, thank god for logic analyzers! My TI is dusty!

  • Like 3
Link to comment
Share on other sites

TOMB (Tombstone City) is an E/A#3 file on Disk B of the TI-supplied E/A disks.

 

attachicon.gifEditor-Assembler Part A.dsk

attachicon.gifEditor-Assembler Part B.dsk

 

...lee

 

 

Thanks Lee. What I am looking for is a raw binary image, I don't have filesystem support done on this platform yet for the TI side, and E/A#3 files are not raw memory images but TI tagged file format. I think I wrote a converter for this format already once, but it may be faster after all for me to just create a new raw image for testing purposes. It probably is the case that raw images are not really available, but stuff is in the E/A#3 format most of the time.

Edited by speccery
Link to comment
Share on other sites

I have a binary that loads at 0xA000 - 0xFFFF. The second 4K of the range is unneeded and is zero padded. It was generated with GCC and prints "Hello World" five times.

 

The zip file contains the binary as well as an additional text file showing the memory map of the binary. You don't need to do anything with the memory map - it is just there in case you want to see how the binary is laid out.

 

Caveat: It worked with the TI (cartridge) headers in there, but the version without headers is untested as I am unsure of how to do so.

noheader.zip

Edited by chue
Link to comment
Share on other sites

After much debugging, I am seeing some signs of life.

I can now load files from the SD card and write them to the SRAM. This is done by the ARM MCU. Verification still sometimes fails (i.e. when the ARM is verifying against a loaded file), but in those instances so far my analysis indicates that the bug is in reading from SRAM. In other words, a second read from the same location yields the expected value, meaning that the write has succeeded. I am testing with a 512K test file spanning the entire RAM.

 

Next I need to check what happens on the side of the TMS9900.

 

REQUEST FOR AN EXECUTABLE: could someone post me an executable binary object I could load to extended memory and launch with Easybug? So I need something that produces visible output on screen, and can be loaded to 0x2000..0x3FFF or to the range 0xA000 .. 0xFFFF, and then started with easybug's E command. The actual address does not matter, as long as it is in extended memory. This must be a raw binary file, no TI file headers, as the ARM code is just reading it off the SD card FAT32 file system and dumping it to memory. I have several programs of my own, but none of them runs from extended memory, they all run from cartridge memory. I could recompile and link etc, but it would be faster and easier to have something that already exists. Thanks in advance! :)

 

 

 

Camel Forth is an <8K binary that loads at A000.

 

With it loaded you can use it like a debugger as well to read and write memory.

 

Any of these should work.

https://github.com/bfox9900/CAMEL99/tree/master/bin

 

There is DUMP utility in MCAMDTC MULTICAM

 

To get to 40 column mode type: TEXT <enter>

 

to Dump memory:

 

HEX A000 100 DUMP <enter>

 

To read an address: A000 @ . <enter>

To write an address: 99 A000 ! <enter>

Edited by TheBF
Link to comment
Share on other sites

Camel Forth is an <8K binary that loads at A000.

 

 

Thanks! Here is the result: https://www.youtube.com/watch?v=Fqk8JFLdBMw

 

The file I loaded was the CAMEL99. It included the 128 byte TIFILES header, followed by a 6 byte E/A#5 header. I compensated for those by loading the image to address 0x49F7A on the ET-PEB RAM (there are 134 bytes of header information, hence not 0x4A000 but 134 bytes before that). The first 4 in that address is there since the memory accessible through AMS memory expansion starts at address 256k or 0x40000 on the 512K RAM of the ET-PEB.

 

The TI-99/4A does not see the memory range 0x49F7A..0x49FFF as that is "under" the I/O range. Unless paging is enabled, that is.

And I am happy to report that paging also works! I have successfully run the AMS memory test, which identifies the system have 256K AMS connected. However, that test does not always pass - there are sometimes errors, so more debugging awaits. But most of the time it does work, so the problem should not be that big...

  • Like 2
Link to comment
Share on other sites

I have a binary that loads at 0xA000 - 0xFFFF. The second 4K of the range is unneeded and is zero padded. It was generated with GCC and prints "Hello World" five times.

 

The zip file contains the binary as well as an additional text file showing the memory map of the binary. You don't need to do anything with the memory map - it is just there in case you want to see how the binary is laid out.

 

Caveat: It worked with the TI (cartridge) headers in there, but the version without headers is untested as I am unsure of how to do so.

 

Thank you chue! Unfortunately this did not work. I disassembled the binary and it seemed fine, at least the first few instructions, but if you have just omitted the header that may not be sufficient, perhaps the remaining image should actually be placed a few bytes above 0xa000 to run correctly.

Link to comment
Share on other sites

 

Thanks! Here is the result: https://www.youtube.com/watch?v=Fqk8JFLdBMw

 

The file I loaded was the CAMEL99. It included the 128 byte TIFILES header, followed by a 6 byte E/A#5 header. I compensated for those by loading the image to address 0x49F7A on the ET-PEB RAM (there are 134 bytes of header information, hence not 0x4A000 but 134 bytes before that). The first 4 in that address is there since the memory accessible through AMS memory expansion starts at address 256k or 0x40000 on the 512K RAM of the ET-PEB.

 

The TI-99/4A does not see the memory range 0x49F7A..0x49FFF as that is "under" the I/O range. Unless paging is enabled, that is.

And I am happy to report that paging also works! I have successfully run the AMS memory test, which identifies the system have 256K AMS connected. However, that test does not always pass - there are sometimes errors, so more debugging awaits. But most of the time it does work, so the problem should not be that big...

 

Hey cool! Glad that was useful.

  • Like 1
Link to comment
Share on other sites

I notice that the title text did not display reliably. I have never tested CAMEL99 on real hardware. :-)

I suspect my VDP routines need tweeking.

 

If you need anything specifc let me know and I can build custom versions with the cross-compiler.

 

Questions for Erik:

 

1. What tool chain are you using to synthesize your FPGA program?

2. Are you using a Papillio board for your 99105 project?

Link to comment
Share on other sites

Sorry about that. I see what I did wrong... the disassembly on this one looks a little better than the last one.

Thanks I will test again when I have a moment.

 

I think I still have some issues to work through to make the design more stable. Today’s version is very much better than what I had just yesterday, and I was really happy to see the memory paging working with AMSTEST. Success rate with that test is about 50%, so every other teat passes completely. That of course is far away from a fully reliable design, but even the failing runs typically only miss one or two memory comparisons during a run which lasts a few minutes. Might be a power decoupling issue, or still a timing problem, just a more rarely happening one.

  • Like 1
Link to comment
Share on other sites

A quick update: I've been continuing to work on the ET-PEB debugging. So far I've added one additional patch wire from the MCU to the CPLD, otherwise the board is as designed. My debugging has been pretty much working on the CPLD design, so that I could make it completely stable. It is inching towards stability, but still occasional errors occur, although now much less frequently than in the past. Judging from simulator runs and observed behaviour I think my VHDL code is correct. However, on actual CPLD hardware there seem to be some corner cases where timing is slightly off.

 

Since there are two memory interfaces, one from the TI to the RAM and one from the MCU, I've been running different tests to on both sides to test the memory arbitration, both using concurrent accesses and only accesses from one processor.

 

I've been using AMSTEST to test the memory interface from TI side - AMSTEST correctly sees the device as 256K memory. I almost thought the memory interface is stable as it passed five test runs without any issues, but then 6th run had two bogus bytes. So it nearly works, but there is still some case where something is wrong. But in principle the design does work, of which I am pretty proud, as I was not sure when I started if the CPLD could actually house a 74LS612 compatible controller (and it cannot, but with help of external RAM it can).

 

I've been loading the entire 512K SRAM from SD card using the MCU and then doing verification by reading the same file again and comparing to values stored in memory. It now passes most of the time. Occasionally there are a few (typically 1) bytes among the 512K that return wrong data. Second read from the same memory locations yield the correct data on the MCU side. That seems to indicate that writes are reliable.

 

I have also done a test program, running in TMS9900 machine code and storing also the workspace in external RAM to stress the memory interface more. The program is loaded by the MCU from SD card and written to low expansion RAM in the range >2000..>3FFF, then started with Easybug. That seems to work fine, even if the MCU is concurrently doing memory accesses. Actually it is very convenient for debugging to be able to observe the TMS9900 register file from the MCU side (via the shell, accessible over USB serial port). I have also done loading from SD card to RAM while the TMS9900 is running code off the RAM, and that has worked too.

 

My next step probably will be assembling another prototype board so that I can do comparisons. Assembling the first board did not go smoothly, so I may have damaged the chips slightly in the process.

I have both 10ns and 7ns versions of the CPLD chips, so far I have been using the 10ns chip. Testing on the 7ns chip might give me different results, if not that also tells something. I may also try to get a slower clock oscillator, currently the clock of the CPLD is 50MHz which may be pushing it given that the macrocells have 10ns propagation delay. The clock does not need to be that high, probably 25MHz or slower would be fine for this design.

  • Like 3
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...