speccery Posted January 22, 2018 Author Share Posted January 22, 2018 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... 7 Quote Link to comment Share on other sites More sharing options...
speccery Posted January 23, 2018 Author Share Posted January 23, 2018 (edited) 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 January 23, 2018 by speccery 4 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted January 23, 2018 Share Posted January 23, 2018 This is most impressive! Can’t wait for a demo! Quote Link to comment Share on other sites More sharing options...
Barry Nelson Posted January 26, 2018 Share Posted January 26, 2018 yes, "PEB-in-da-Speech" would be nice As long as I can somehow still connect the speech synthesizer it's fine. Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted January 27, 2018 Share Posted January 27, 2018 I decided to call it simply Erik's Tiny PEB, as this is supposed to be small(ish). This is in the spirit of time Quote Link to comment Share on other sites More sharing options...
christophlee Posted January 27, 2018 Share Posted January 27, 2018 Please put me on the list to buy one of these. Quote Link to comment Share on other sites More sharing options...
speccery Posted January 29, 2018 Author Share Posted January 29, 2018 Please put me on the list to buy one of these. Thanks for the interest - once I get this thing debugged and working - and production planned - I'll be sure to keep yo in mind too. Quote Link to comment Share on other sites More sharing options...
speccery Posted January 29, 2018 Author Share Posted January 29, 2018 (edited) 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. 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. Below the SD Card slot can be seen. Edited January 29, 2018 by speccery 8 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 29, 2018 Share Posted January 29, 2018 Ooooooh..... 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 29, 2018 Share Posted January 29, 2018 Really nice work. And a very much needed device as well! 1 Quote Link to comment Share on other sites More sharing options...
speccery Posted February 1, 2018 Author Share Posted February 1, 2018 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! 3 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 1, 2018 Share Posted February 1, 2018 Exciting progress, no doubt!! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted February 2, 2018 Share Posted February 2, 2018 TOMB (Tombstone City) is an E/A#3 file on Disk B of the TI-supplied E/A disks. Editor-Assembler Part A.dsk Editor-Assembler Part B.dsk ...lee 1 Quote Link to comment Share on other sites More sharing options...
speccery Posted February 2, 2018 Author Share Posted February 2, 2018 (edited) TOMB (Tombstone City) is an E/A#3 file on Disk B of the TI-supplied E/A disks. Editor-Assembler Part A.dsk Editor-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 February 2, 2018 by speccery Quote Link to comment Share on other sites More sharing options...
+chue Posted February 2, 2018 Share Posted February 2, 2018 (edited) 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 February 2, 2018 by chue Quote Link to comment Share on other sites More sharing options...
+TheBF Posted February 2, 2018 Share Posted February 2, 2018 (edited) 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 February 2, 2018 by TheBF Quote Link to comment Share on other sites More sharing options...
speccery Posted February 2, 2018 Author Share Posted February 2, 2018 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... 2 Quote Link to comment Share on other sites More sharing options...
speccery Posted February 2, 2018 Author Share Posted February 2, 2018 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. Quote Link to comment Share on other sites More sharing options...
+chue Posted February 2, 2018 Share Posted February 2, 2018 Sorry about that. I see what I did wrong... the disassembly on this one looks a little better than the last one. noheader2.zip 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted February 2, 2018 Share Posted February 2, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted February 2, 2018 Share Posted February 2, 2018 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? Quote Link to comment Share on other sites More sharing options...
speccery Posted February 2, 2018 Author Share Posted February 2, 2018 Hi TheBF, It is useful to rest with other software than my own stuff, so thanks again! 1. I am using Xilinx ISE 14.7 2. The TMS99105 project is using the Pepino board from Saanlima electronics. The project is documented at hackaday.io Quote Link to comment Share on other sites More sharing options...
speccery Posted February 2, 2018 Author Share Posted February 2, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
speccery Posted February 4, 2018 Author Share Posted February 4, 2018 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. 3 Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted February 4, 2018 Share Posted February 4, 2018 If you need a program that uses AMS I can provide one for testing. It uses under 256k so it should be fine. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.