Jump to content

speccery

Members
  • Content Count

    546
  • Joined

  • Last visited

Everything posted by speccery

  1. Yes, time is the problem, isn't it. Some of the things, such as detecting sprite collisions, becomes very easy with the original approach, just a simple four input logic gate will do the trick. 112KB is quite a lot of memory already. I haven't optimised internal memory use too much yet, currently the icy99 uses around 96KB but that can be reduced easily. For instance system ROM and GROMs are stored on-chip, although that is not necessary. I am planning to increase VRAM to 64K. That would be a sizeable increase and enable some further extensions (along the line of 9938/9958/F18A). Having said that I am enjoying the simple 80 column mode a lot. These are very cool projects you have lined up, good luck with them !
  2. One more thing - for me "python" runs python2, I am wondering does it link to python3 on your development system? My understanding is that just "python" normally would launch python2 and python3 needs to be explicitly specified.
  3. @jedimatt42 thanks for the support & pointers, I'll take a look. I might add the F18A style 80x30 mode with extended attributes to icy99. Having the ability to have per character cell attributes seems a lot better than only having the 80x24 2-color display - although that is a huge improvement over the 40 columns mode.
  4. Thanks @jedimatt42 for your comments. I clearly jumped into conclusions too fast. The reason for my messy conclusions were that I didn’t have enough time to properly go through things step by step again. The root cause is probably the lack of xdt99 on path, which manifests it self with the weird python3 command line. The reason I was thinking that recurse submodules was necessary was simply that for some projects it is, so it’s one of things I try when something is not working. Here it appeared something was lacking (what was lacking was knowledge how to build fcmd) so I tried it out, while apparently also adding xdt99 suite to the path at the same time. I first thought fcmd is built by running make, only to later discover that there was the build.sh script. Secondly, I was building for the first time gcc simultaneously on both my desktop and on the TIPI. I wasted some time not realising the installation script for gcc, which took care of all steps in one go (apart from installing the few unusual dependencies). It was not obvious to me that the gcc can built and installed simply the installation script, I was scrambling the patches first. In other words, I was working on multiple projects I am not familiar with. Still, miraculously the outcome was a seemingly working fcmd. I loaded both the cartridge ROM and GROM, but is it so that only the cartridge ROM is needed? My preference is to build things from source, that way I can more easily change something if needed. As one example currently the width command of fcmd does not recognize icy99 (which is not surprising), so I cannot get 80 columns to work yet. It will be interesting to see how it detects the VDP type.
  5. I was about to ask how I should get this working with the TIPI. I am testing Force Command with icy99. After some head scratching I should kick myself, I forgot to load the DSR for TIPI. Once that was done Force Command seems to work fine, and it talks with TIPI too. This is the version I compiled from source, so very cool. At last as far as the "dir" command is concerned; it gives me the home directory of the user tipi listed, but I don't seem to be able to change to change directory to DSK1... Need to learn how to actually use this. It is interesting that a reset throws me directly to Force Command - cool and unexpected! A whole new computer!
  6. I am yet again learning about cool TI-99/4A projects. This one looks really cool, and useful! I tried to compile the current version in github (to test drive my fresh build of gcc for the TMS9900), and ran into a few issues. The good news is that gcc compiled a whole lot of stuff, so that was good, but python3 was not happy: Initially I was using python 3.5.3 (on Debian stretch running under WSL) and it does not support the f"..." style strings. Upgraded python to 3.9, but next I ran into this problem: python3 -D "CART=>601e" -o FCMDG.bin gpl-boot.g99 Unknown option: -D usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. Which version of python I should be using? EDIT: My bad. I should have cloned the repository with git clone --recurse-submodule https://github.com/jedimatt42/fcmd.git instead of straight clone. In addition to this, I needed to edit xdm99.py so that it uses python3, so I modified the first line of xdm99.py: #!/usr/bin/env python3 With these changes it appears that on the TIPI the compile was successful.
  7. Thanks @pnr for the links! My TMS9918 takes currently around 1100 lines of Verilog. The line count is somewhat impacted by the support for ICE40HX FPGA chips. They don't have true dual port block memories and there is not enough on-chip memory for 16K VRAM and linebuffer. The former leads to the need to use two memory blocks in parallel for rendering and the latter requires an interface through which data from external RAM can be used. The use of external RAM complicates things quite a bit, since I also built in some pipelining to be able to use the external memory bus efficiently. I also added the ability to read registers back, which was useful for debugging. And finally my TMS9918 core has some unnecessary states, which could be removed by modifying the sprite drawing logic a bit. All of these probably add quite a bit of code, but probably more than what your target line count would be. Even if you built a version which is close to real silicon, you would need to build a scan-doubler to support modern monitors. Anyway, this is jus a long of saying that if you want to use my TMS9918, let me know and I will tidy up the code to make it easier to read. I am planning to clean up the code when I have a moment, also to make a version which does not have the external memory support to simplify the core. The 99095 is a very cool name! And a cool core as well! With regards to the TI-99/2, it would be interesting to port the Basic from it to the 99/4A. That would be quite a bit faster, as it is not using GPL to my understanding.
  8. And I just tried again Dungeons of Asgaard - and it works. I did not do any changes. The only difference to the tests I ran yesterday was that TIPI was not initialized (i.e. TIPI DSR ROM not loaded). There could be a bug in the logic in the DSR area decode. Need to run the memory tests again after installing TIPI and using a little. EDIT: After some more testing, both Dungeons of Asgaard and "In the dark" (IDT, disk based game for RXB, uses both disk and SAMS at the same time) work just fine. I think the issues we saw in the zoom call were simply that the FPGA was not reset properly beforehand. Resetting disables SAMS and sets the cartridge ROM paging register to zero (among a ton of other things). From a clean reset both DoA and IDT work well.
  9. Thanks @pnr for pointing that out to everyone here, in case someone is interested. In addition to the computers you listed, there is also the Tomy Tutor which I've been thinking to support. It's a simple computer, and with all the parts of TI-99/4A available should be a simple thing to do. Probably TMS9995 instructions would be needed. Could you provide links to the TI-99/2 and Mini-Cortext? I participated yesterday (evening my time) to the pandemic TI-99ers Zoom call. That was fun, and nice to be able to have some more faces associated with names I was showing icy99 during that call a little - completely unprepared as I forgot the call, but thanks to @kl99I got a reminder and joined in. I asked for recommendations of software using SAMS extended memory - and Dungeons of Asgaard was mentioned I tried it during the zoom call. Unfortunately it didn't work. Could be a problem with the memory extension, or could be something else. Icy99 is starting to be at a reasonable good state, but of course it has only been tested by (well and some people in the ULX3S community, but I doubt many of them have lots of TI-99/4A software to test). @jedimatt42 thanks for the suggestion of using your memory test software to test further the icy99 SAMS implementation. I've been running it a while and all the tests pass.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. Thank you - I look forward to testing it more! Great project!
  15. 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.
  16. 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!
  17. 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.
  18. 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
  19. 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.
  20. Just discovered this thread - is there another one coming in two weeks?
  21. 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.
  22. 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.
  23. 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.
  24. 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....
  25. 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?
×
×
  • Create New...