Jump to content

speccery

Members
  • Content Count

    512
  • Joined

  • Last visited

Community Reputation

839 Excellent

About speccery

  • Rank
    Dragonstomper

Recent Profile Visitors

4,338 profile views
  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....
×
×
  • Create New...