Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by speccery

  1. Well spotted, I was thinking that somebody will recognize it. I am a bit of Raspberry Pi fan, I attach here a picture of Pis on my desk as well as a family photo of the ones on the shelf. Some are missing from these pictures, I seem to have hoarded a few of these over the years... For example I have (most of the time) in my work bag a Pi 4 with a SSD drive with icy99 development environment, you never know when inspiration hits. The family photo
  2. Yes, for sure a switch could be added. I am going to add a hotkey for that. I already use F1 to pull up the overlay screen for ROM loading, so perhaps F2 should pull up a configuration screen.
  3. You probably were referring to my comment on it being SPI. At the time I assumed it was SPI. On closer inspection there is also a parity bit, so this is not your SPI. SPI comes in may flavors, depending on which clock edge data is shifted out and sampled by the receiver. I also note that there are multiple shift registers in the design. I haven't looked at the Rasberry Pi code yet, but I assume the code is just bit banging the data. I need to push to Github my Verilog changes to the code, but I should clean up the code a little first.
  4. I am happy to report that TIPI works well with icy99. I am actually very impressed with the functionality that TIPI brings to the table - with very little effort on my part. I have just scratched the surface, and I am using just DSK1 and DSK2 support for now. But this TIPI + icy99 combination is a bit of game changer for me. I can now focus with good conscious on some of the cool things I want to add, now that disk support is already there. As was briefly mentioned in the Facebook discussion at the TI99ers group, I want to add 1M SAMS memory support and also GRAM support while at that. And then there are other things, such as expanding VRAM to 64K and adding support for extended attributes in the VDP. And I should slow the system down to original speed, if I can somehow resist the urge to make the system go very fast. With the TIPI support and 1MB of RAM it feels like having much more CPU power would be cool again... Unlike with my first EP994A core, I haven't this time around focused on the TMS9900 core performance too much. I just ran a simple extended Basic test program, and it runs at 4x speed on the icy99 compared to the real iron, so plenty fast, but nowhere close to the 30x performance with my first implementation. The icy99 CPU core is a little faster per clock, but it runs without a cache, with SDRAM, and at a quarter of the clock speed. I need to tidy up the cabling by rearranging the pins on the FPGA side, so that I can just use a flat ribbon cable. My video (linked in the above message) explains the setup better, but the picture here shows the cabling arrangement, which is unnecessarily flaky. Here icy99 is running TurboForth in 80 column mode.
  5. Thank you - I look forward to testing it more! Great project!
  6. Thank you and thanks for the list of videos - this is such a great forum as one gets support superfast and to the point! I am well aware of how the TIPI interface works on the hardware side, as I needed to modify the Verilog code designed for the CPLD chip somewhat to interface properly to my FPGA core. But software side not so much yet. I have written a DSR for my previous FPGA design, so I know how those work. The CPU core in the FPGA runs much faster than the normal TMS9900, so I was ready to see some problems, but like you say, once the serial communications works, it pretty much just works.
  7. I posted a video of my icy99 FPGA system working with TIPI. At least to the point that my TI-99/4A core can communicate with the TIPI enough to show TIPICFG. I suppose next I would need to learn how to actually use the TIPI, as it's the first time I've done anything with it. The TIPI project is impressive for sure!
  8. If memory serves me right, here is my first video of the icy99 project! I hope you find it interesting and at least get a smile out of it Demoing some general stuff, Parsec, TurboForth and TIPI. The video is here on youtube.
  9. I've worked a bit on integrating TIPI support into icy99. I am now at the point where the next step would be to simply connect the around 8 wires between the FPGA board and Raspberry Pi. So getting into an exciting phase. So far this integration has been interesting for many reasons: I know (or I should say knew) almost nothing about the TIPI, except that it runs on the Pi and connects via SPI bus (implemented with a CPLD) with the 99/4A. By the same token, I have never operated the TIPI. It is interesting that the TIPI is also a Verilog design, and there are not many of these for the 99/4A As such, it was an interesting exercise to connect these two blocks together. Basically connecting a peripheral intended for the TI-99/4A to a TI-99/4A. Basically simple but a good reminder that my signals within the FPGA are not the same as one one would find on a regular TI-99/4A. A couple of major differences: for one, as is usual with FPGA designs, my design is fully synchronous and running from a single 25MHz clock. Everything occurs in sync with this clock. I don't have a multiple phase clock. Secondly I don't have the exact signals one normally finds on a TMS9900: I don't have #MEMEN (instead synchronous RD and WR signals, and #MEMEN can simply be generated with NOT (RD OR WR)), and I have an actual CRUOUT which is not multiplexed with A15. A third difference is that there are no three state bidirectional buses: there are separate data read and data write buses (with the exception of the bus connecting to off-chip SDRAM, which is a bidirectional data bus). The fourth difference is coding style, but this is a matter of taste. I have TIPI software installed on a PI 3B+, and I can connect via ssh to it, so that part should be ok. On the 99/4A side the TIPI DSR is loaded, so not much remains - in theory. In practice I want to reserve at least a few hours to work and debug on this in one go, as I don't expect this to just magically start working - although it could happen
  10. Thank you @Lee Stewart it would be interesting to join. The 10 hour time difference is a bit of challenge though, Sunday 3PM translates to 1AM on Monday for me. The Sat 11AM is a more manageable 9PM, so need to wait a week then.
  11. Just discovered this thread - is there another one coming in two weeks?
  12. Yes I am thinking about MiSTer too. My primary hesitance about it is simply that I still have all the parts in a box and I haven't put mine together. I have done test synthesis (of another core) for the MIST, so I know working with that is not a problem, but haven't done the same yet with MiSTer. It should not be a problem either, but haven't tried out the toolchain. Having said that, for something like the Geneve the other platforms are also easily capable enough. As one example, the Lattice 25F can support the Commodore Amiga Minimig core on the Flea FPGA Ohm board.
  13. A bit more progress, now I finally added sound support to the icy99 (for the ULX3S FPGA board). This of course makes a big difference to the gaming experience. There is still some more low hanging fruit, support for 1M AMS is probably next. For file system support it seems that the easiest way to get going is to just integrate the TIPI interface. I was planning to make this weekend a video of the current state of the project, but ran out of time, hopefully in the next few days. In case anyone is interested, I noticed that at Mouser they have some ULX3S boards in stock. These are with smaller 12F FPGA - with the open source tools this can be used as 25F, Lattice 12F and 25F chips are the same by their own tools don't enable one to use the 12F as 25F). I am using the 85F boards for development, but people in the ULX3S community have told me that the design works also on the 12F boards. Since the icy99 uses a very modest 25MHz clock speed, and I have been targeting four boards in the beginning, the design should be fairly portable. I haven't in a while synthesised versions for other boards, but I plan to pretty soon do that. I also want to give porting this to the MIST a go.
  14. Since the MiSTer port of the 99/4A is based on my code I guess it starts to be the time to put together MiSTer myself too, have had the parts lying round a long time. I tried the MIST port a while ago, as I know how to operate MIST. I've been recently working on the icy99 version which is better (IMHO) structured but not done yet. I am planning to add TIPI support to icy99, as that should (?) be quick way of getting disk support.
  15. Thanks for the link! There are no 16k*8 DRAM chips. I suppose the closest would be to use two 64k*4 DRAM chips (4464 DRAMs). This would provide 64K of VRAM, of which 16K would be used, the highest address line would need to be a constant. I am not 100% if the DRAM refresh would work in this case though. I've seen the circuit you referred to before, for example here is something similar: https://www.tindie.com/products/mfkamprath/tms9918a-video-card-kit-for-rc2014/ It could be simplified by integrating all the logic into one CPLD, for example XC9572XL could do the job, then you'd have the 9918, CPLD and SRAM. The whole VDP+VRAM can be contained also in one FPGA, like I have done for example in my ICY99 project. But if one wants to retain the original TMS9918 (or TMS9928) then I think the lowest chip count is with the CPLD+SRAM solution. Thinking about it, if one wanted to use the original TMS9918 and TMS9995 - and it would be acceptable to use a CPLD, I think the Jr could be reduced five chips: TMS9995, TMS9918, SRAM for VRAM, ROM and a CPLD for everything else. hmmm... this would be a fun project to do! Although I would add one more SRAM to provide RAM for the TMS9995. And I do have all of this chips already at hand. hmmmm....
  16. Thanks! Considering that there are 8 DRAM chips for the VDP, they really have simplified it! It appears they've removed the keyboard interface and probably some other things too. Could you share the URL as well?
  17. Just now discovered this thread. Since there are schematics above, it seems there is all the necessary information to make FPGA version of the Tutor. I've built a TMS9995 system on breadboard in the past, but it's been a few years ago. It's mind-blowing how they just copied the TI-99/4A. Still no proper CPU RAM (sigh). Notably in the schematics VDP_CS is in the same address for both reads and writes, since the TMS9995 does not perform a read operation before each write, unlike the TMS9900. The TI-99/4A places VDP read and write ports to different address in order to avoid problems with these reads to write ports.
  18. Thanks, interesting! So based on what you wrote in the other message, they only would use the internal RAM of the TMS9995 CPU and VDP memory.
  19. And another thing: I would be interested in adding Tommy Tutor support to my icy99 project, as I'd like to have at least a FPGA version of it. My understanding is that the Tomy Tutor is basically TMS9995+TMS9918+some simple discrete logic, so implementing it in FPGA form would be probably simpler than for example TI-99/4A.
  20. I'll throw in my 5 cents: - I recently wrote a TMS9900 disassembler in C (I used it when running simulator of my Verilog TMS9900 - GTKWave which I use for simulation result display can interface with an external program for decoding various things). If you want to use it just let me know. It's a simple stateless disassembler. It currently supports only TMS9900 instruction set, not TMS9995, but adding those instructions would be trivial. - If you want I can create for you a table of all 64K opcodes with the aforementioned disassembler. - I would also try out xda99 (written in Python by Ralph Benzinger) for disassembly work. I use his xas99 all the time. - Forgive me not being familiar with Tomy Tutor, but why would it use GPL? Did they license the Basic from TI? Otherwise I don't understand why they would have used GPL. If I was them I would have done the Basic interpreter etc. in normal TMS9995 assembly code. - With regards to the comments made above, it's good to note that sometimes programmers embed data words in machine code. For example I have used in some of my assembly programs a simple setup where after a BLWP to a routine there are some data words which are parameters to the routine called with BLWP. The routine being called advances the return address as it uses that data, so it will return not to the address immediately after the BLWP but sometime later. The same thing can happen with BL and XOPs. However, these type of parameters are typically only a few words long and will not throw a disassembler off course too much.
  21. Thanks @Asmusr very helpful! I had a rather spectacular bug - the early clock bit setting was not reset after sprites were done, causing the early bit to impact succeeding characters. This whole test and bug fix took only something 10 minutes. Below pictures before (with bug) and after (bug fixed). The bluish ball is partially visible on the left hand side. My 4K monitor supports PIP mode, so the HDMI coming out of ULX3S goes to my monitor and I've set the picture to bottom right hand corner. with the bug And after fixing by resetting the early clocks after done with sprites:
  22. I think I have now fixed all bugs related to TMS9918... Well not quite. Megademo now seems to run correctly, except for the multisplit_demo.a99 which does not correctly display the splitscreen material. I think I need to check what happens with my VRAM memory address pointer when changing modes. The sprite coincidence stuff now seems to work correctly. I also had a couple of other bugs, with sprite behaviour with early clock bit set (left edge) and rendering not stopping at the right edge. I had a hard time finding any software to test sprite bleeding in from the left: I did not realise it before, but Extended Basic does not support setting the early clock bit: sprite coordinates range from 1 to 256, no option to set negative coordinates to test sprites partially displayed from the left. I only tested the behaviour with iverilog simulation then, and it seems to work there. I thought that at least the UFO in TI Invaders would nicely enter pixel by pixel from the left but nope, it just appears out of nowhere completely. On the right edge it does disappear and enter pixel by pixel, I guess they didn't want to spend a few more bytes to do it nicely on the left edge too. And while in the topic of wondering and ranting about Extended Basic: CALL SPRITE: Why the heck is the coordinate system not zero based? 1 to 256? I did not realize this before, especially when coding as a kid Still on CALL SPRITE: what is the deal with the hash sign for sprite numbers? It seems completely superfluous syntax and only consuming valuable RAM. (After writing the entire message I realised that perhaps CALL SPRITE allows multiple sprites to be instantiated with one command, in that case the hash makes sense - but I still don't like it and the lines are very long even with one sprite declared). Sprite auto motion is kinda cool, but at the end of the day seems unnecessary since Basic code anyway is not fast enough to check where the sprites are driving around. I used slow speed sprite moving for checking my TMS9918 implementation, and discovered that it does not move all the sprites at the same time. I had a whole bunch of sprites on screen with horizontal speed -1, and they did not move at the same time. Perhaps that's just because in Basic one cannot start more than one sprite at the same time (given the slow speed of Basic). Another reason why automation is not useful... And why does Basic editor & listing not use the first column/columns??? Valuable screen real estate wasted! This next one is a bit specific: I am using PS/2 keyboard connected to the FPGA board. To edit lines as probably everyone here knows you enter the line number and push cursor up/down to call the line for editing. Half the time I accidentally pressed enter after the line number - deleting the line. And of course there is no command line history nor undo... I have to say I miss dearly those features. User error for sure, and it comes with a hefty punishment - but not as hefty as pushing QUIT accidentally - of course no confirmation is asked, and the Basic test program is gone... Enough ranting there. The other FPGA feature I added was cursor key navigation for the on-screen display on the ULX3S board. Now hitting F1 brings the OSD up, and cursor keys can be used to navigate the SD card and load GROM and ROM data.
  23. Thanks, these are really good reminders! I am thinking about refactoring the sprite generator somewhat, since it's gotten a bit too complex by now.
  24. I've worked a bit more on icy99. This time I actually had time to work on it, but the bugs I was wrestling with were surprisingly difficult to identify. My test case has been Megademo. In addition to being great to look at, it also exercises many features and is very good for uncovering bugs. I fixed two bugs: multicolor mode, and a bug which manifests itself in the very first phase of the demo (stretch.a99). The fixes for both bugs were super simple - once I knew what to fix. Fixing the multicolor bug took probably only an hour, I was setting the pattern for shift register and the colors a little incorrectly. This was harder to find than it needed to be, since I didn't remember when reading the Verilog code that I have some states where the state machine can stay for rather long, and it processed the correct data in the first cycle, but then overwrote the correct data with bogus data on the next cycle while waiting for the bit shifter to become available. I spent way too much time wondering and fixing the bug in the stretching effect: in order to be able to understand what the heck was going on, I finally had to take UART output into use, and modify the stretch.a99 code so that it initialises the TMS9902 UART and writes hexadecimal words every now and then. So normal printf() style debugging, but in assembler. Eventually after suspecting bugs in the CPU etc I found out that the data which is streamed from memory to screen in this demo is split across multiple 8K pages (when loading from cartridge). I had bug in cartridge paging: when I extended it to 2 megabytes, I forgot to widen the page register assignment, and only 5 bits were written to the 8 bit page register. This limited the cartridge size, as seen by the TMS9900, to 256kbytes. It just so happens, that the code and a portion of the data in stretch.a99 were in the last page in that 256K region, but most of the data are in the next two 8k pages, which was above the 256K region size. So the CPU got just random data when reading them (or not random, but data from other unrelated pages) and that caused a messy display. The fix was simple, but finding the culprit probably took something like 8 hours... Well at least in the process I have improved my debugging tools. At least one bug still lingers, the splitscreen3_demo.a99 uses the sprite COINC flag to get access the VDP's vertical position counter. I have already worked on this bug in the VHDL version of the code and fixed it there (yes two times the same bug seems to the charm here). It appears that my Verilog implementation of COINC works, except when the sprites bleed in from the top. In this demo effect the first vertical coordinates seem to be -2 (or 254). This should trigger COINC on the first scanline, but due to the bug COINC is never triggered, and the demo just halts. At least that is very noticeable, and the bug also manifests itself in my Verilog test bench for the VDP, so this should not be too hard to fix.
  25. Continuing a bit off-topic (I have also worked on the icy99, more about that shortly). I committed the first version of the small TMS9900 system into GitHub. I seem to have forgotten how to link album picture to posts, but anyway below is a picture of the UPduino V3 board.
  • Create New...