Jump to content

speccery

Members
  • Content Count

    477
  • Joined

  • Last visited

Community Reputation

754 Excellent

About speccery

  • Rank
    Moonsweeper

Recent Profile Visitors

4,195 profile views
  1. Thanks for the comments @Asmusr and @Lee Stewart. I quickly looked at my code, and currently it is only looking at the 3 LSB bits for register selection, but expanding that is trivial. I actually have already extended the interface to my TMS9918 last year, so that instead of the VDP only decoding one bit from address bus, I have a 8-bit address bus and support a bunch of 16-bit registers which can be read by the CPU. For reading, in addition to reading from address 8800 and 8802, with my VDP there are 16-bit wide registers in the range 8880..88A0, enabling reading back all registers, with proper bit shifts to have the direct VRAM addresses for all tables, and additionally the VRAM pointer can be read, the screen refresh row and column, whether the display is in the blanking area, plus some debug stuff.
  2. Thanks @Asmusr this is what I was looking for! I would initially be looking to implement a super simple 80x24 mode - but still something that at least some software can directly utilize, it can be made fancier later. It would be a nice addition to the icy99 code base. If it as simple as adding one more bit, this should not take long at all to implement (if I had some time, but that is another story).
  3. I bought mine directly from them, by e-mailing the contacts I got from @pnr. There is also crowd supply campaign at https://www.crowdsupply.com/radiona/ulx3s, and I did order another one probably around 6 months ago. Their delivery schedule has slipped, and is now supposed to be in August. I believe you can order directly from there. And as I wrote this while catching up the thread, I see that the question was already answered... Self assembling the ULX3S is not an easy option, as the ECP5 FPGA is BGA chip, and there are a ton of other components on this board.
  4. Thanks for sharing, sounds interesting. That sort of WP manipulation possibilities are certainly unique to the TMS9900 and TMS99000. Luckily TMS99000 instruction set seems to also add support for normal stacks
  5. I just remembered that I wanted to ask how much 9938 VDP features I would have to add to support 80 columns text mode? For example to support fbForth or TurboForth with 80 columns? I hope that this would not require too many additions. Internally my VDP core already renders pixels to a 512 pixel wide buffer, so the underlying engine has been partially designed with 80 columns in mind. To be more specific, I guess what I am asking is that what extended registers I would need to add to support simple 80 column mode?
  6. A quick update: I have been working together with the ULX3S developers to make the icy99 implementation on the ULX3S FPGA board better. emard and lawrie have been testing the TI-99/4A core. emard added support for the screen overlay feature he is using with many other retro computer implementations. The cool thing is that this is running on an ESP32 micro controller running micropython. The overlay screen already allows loading of ROM images from SD card. When I have time I will continue to work on the core itself, for instance to add support for disk subsystem with the ESP32. I can probably reuse some of the code I created for my ET-PEB project. In the process I accidentally broke my FPGA board, the primary micro USB socket became loose and broke the PCB pads in the process. Luckily I could fix this with a new micro USB connector, as it is the same connector used in my StrangeCart board. Some pictures are here in the gallery.
  7. speccery

    ULX3S FPGA broken USB connector

    The micro USB sockets can sometimes become loose. I managed to fix my FPGA board by soldering a new socket. The old socket got stuck on the plug, and ripped the PCB pads.
  8. Just published the current version of the Icy99 at icy99 (github) due to some interest from the ULX3S development community. Thanks @pnr for informing about that - and for digital video interface as well TMS9902 cores used here.
  9. The Blackice-II board which I was using as the primary design target when writing the above only has 512K of memory in total. Thus I was trying to come up with an allocation of that memory which would support most use cases. Clearly it's not possible to allocate 640K for GROM/GRAM space when there is only 512K to work with in total On other boards, such as the ULX3S, there is a SDRAM chip on board. It provides 32 megabytes of memory, but I'm not yet supporting that in this design, although I have earlier worked on another board with SDRAM providing system memory for my TMS9900 core. With that kind of memory space it becomes possible to support the full GROM space, as well as full 1M AMS memory space. I don't actually even know what would be a reasonable amount of memory to allocate for GROM content? If memory serves me right the Ubergrom supports around 100K of GROM spacce. I was thinking that 40K of cartridge GROM space would support pretty much all individual GROM programs, but of course it is possible to have multiple programs in different GROM bases simultaneously.
  10. I ported the Icy99 again for the ULX3S FPGA board. I looked at my notes, in this thread actually, and I can see I did port it before. But I couldn't find the files anymore, probably since I only have some of my computers in the temporary apartment we're staying (moving to permanent location next week). I clearly use too many computers for the same stuff... Anyway it was not a lot of work to port the design from the Flea FPGA Ohm files, as both boards use the Lattice ECP5 family FPGA chips. Once I got the porting done and started to look at the cause of the VDP video bug I mentioned above, and it only took me 5 minutes to both find and fix the bugs. Sometimes it helps to to return to a project after a pause although I wouldn't recommend 6 month pauses... The basic problem was that my verilog code checked for end of scanline and end of frame conditions in a stupid way: if a CPU memory access would occur while the logic was waiting for the said event, the logic would miss the event... The fix was simple, just moving these end of line/frame checks to their own parallel blocks, evaluated on every clock cycle. Now the image is solid, although the first scanline repeats now for lines, so there is an edge condition still needing fixing. I'm still only using internal block memory on the ULX3S. The ECP5-85 chip has over 400K of internal block RAM, and I am now using just over 100K to support the 99/4A, system ROMs, system GROMs, 32K RAM expansion, VDP VRAM, 16K cartridge ROM space and 32K cartridge GROM space. I am now wondering how I could connect strangecart to the FPGA design, as that would be a fun exercise. Perhaps I will just go with a simple SPI bus, as that would only require four wires. The code on the StrangeCart side would need to be changed, so that instead of listening to the parallel TMS9900 address & data buses it would get the address and data over the serial bus. Also, the FPGA would need to capture reads and writes to cartridge space and transfer the data in SPI format. If the SPI clock is something like 25MHz I would get very close to the bandwidth of the standard cartridge interface: 16 clocks to transfer address, perhaps 8 bits for command (read/write, ROM/GROM), and 16-bits for data.
  11. Thanks Jim for the link, unfortunately I'm having a hard time downloading the file, but retrying seems to work, fingers crossed... Big file.
  12. Hi Tony, thanks for the comments, very interesting. As is discussed before in this thread, I have three TMS99105 chips, and at least one of them seem to have the TMS99110 floating point macrostore ROM. I am curious, what were the systems you were involved in using the TMS99000 series chips outside of TI?
  13. That is in fact what I was thinking of doing, i.e. just have along stream of LI R0 instructions (and perhaps occasional LI R1 to update VDP pointer) in cartridge memory. This way you would have sections of the TMS9918 VDP memory exposed to the ARM processor, so that every 4th byte would be VDP memory byte and the rest code. I was thinking that at the end of each long stretch of LI R0 instructions there would a branch to the beginning, and that branch instruction fetch could cause the ARM side to switch to another "ROM" bank. That would a simple way to synchronise the ARM and TMS9900. While the TMS9900 is running through one stretch, the ARM would generate the next.
  14. Interesting picture. Since I don't have a PEB, I am always learning about new things that were designed for the PEB. And continue to be intrigued by these. As I know nothing about the board, I guess I can make completely random comments: it appears the Z80 could be controlling a printer buffer. There is 64K RAM on board. Looking at the PCB design it would be interesting to be able to read what chip U5 is, as it seems to sit between the Z80 computer and TI's bus. Looks like they basically slammed a full CP/M computer on board
  15. Thanks for sharing your thoughts, interesting discussion here. When you say that the bandwidth is around 2k per frame on the TI, what is the frame rate you're assuming? Probably not 60fps, more like 30fps?
×
×
  • Create New...