speccery

Yes that's true, I was reading the technical description the other day and indeed it uses DMA cycles by asserting the DMA request and stealing the bus. This is in contrast to ZX Spectrum, VIC-20 or C64 which also steal cycles but for the most part it goes unnoticed, since the memory bus is effectively running at twice the speed of the CPU. Probably something similar could have been done with the 99/2, but with additional cost. Looking at the pictures in this thread the system is using HM6116LP-4 SRAM chips, which have a cycle time of 200 ns, thus from the viewpoint of RAM chip speed it would have been possible to multiplex the RAM between VDP and CPU. Of course one would have needed those multiplexers as additional cost.

Not that it matters to anyone else than me, but just want to share the two TMS9995 chips I recently purchased both seem to work perfectly. Tested these on the Mini Cortex board. Was nice to see boot message, I seem to have last working on the boot ROM in 2016 as that what the boot message says...

I want to bring a different point of view to this discussion, which seems to favour BLWP or BL. At least personally, for assembler programs, I very much prefer BL over BLWP. For leaf routines (which don't call other routines) you don't need the stack of return addresses, and you can just do BL @ABCD and B *R11 to return. Comparing BLWP and DECT RP, MOV R11,*RP, BL @routine is not in my opinion fair, since the latter supports recursion and is more flexible in that regard, while the former does not. One should add similar code to BLWP to support multiple levels of calls. And that really becomes involved, something like STWP Rx, AI Rx,-32, MOV Rx,@somewhere+2, BLWP @somewhere. In general you want to keep your workspace pointer in the scratchpad memory. This leads to static allocation of workspaces in the scratchpad if you want to use BLWP, not as flexible as with manual stacking of return addresses. Plus you run out of scratchpad space real fast when putting multiple workspaces there. One also needs to be careful when using BLWP and a non-trivial program, since if the routine called to with BLWP shares this workspace with other routines, unexpected results might arise if one expects the workspace to preserve its state. When using BL, since you're not changing the workspace pointer, you can quickly and easily access the registers of the calling routine with direct references (Rx), without using something more error prone with offsets like MOV @4(R13),R7 to get data from the caller's workspace. For all of the reasons above I guess all compiler generated code uses BL and not BLWP.

I'm not sure if I understand the implication here to what I am planning to do. With regular extended basic and system GROMs, the first seven 8k GROM slots from >0000 to >DFFF would be already occupied, leaving the last slot at >E000 free. That's irrespective of whether the occupied GROM slots use 6k GROMs or 8K equivalents, since to my understanding the legacy console software is looking for GROM headers at 8K intervals. The easiest thing for me would be to just have a single GROM only for the DSR support (6k or 8k doesn't matter, I only need probably 1k or something like that), not having to modify any of the existing GROM headers or mix my code with existing code. In order to fit this DSR GROM image in the GROM memory space when extended basic is loaded, it would have to reside at >E000, since that's the only available slot in the 64K GROM base 0 (read address >9800 in the CPU's memory map). With RXB and other extensions I believe that not only are 8K GROMs used, but also they have 5 GROMs instead of 4 in the legacy extended basic. Which means that without decoding the so-called GROM bases, the 64K GROM memory map is full, and there is no space left to put my DSR without merging it with other code in a given cartridge. Further, to my understanding neither the extended basic cartridge nor the console GROMs support the multiple GROM bases in the sense that they don't decode fully the lower address bits, but rather they occupy all of the 16 bases. Thus with a standard extended basic cartridge, the first 56K of GROM space behaves the same way in all of the 16 bases. Having said that, with the StrangeCart I could support the different GROM bases easily, so I could force extended Basic or RXB or whatever to only appear in GROM base 0 (at >9800). In that case I could put my DSR for example to GROM base 1 (read address >9804) at GROM address >6000, and there would be no conflicting overlap. This should work if all the software uses properly the GROM base addresses and is able to remember and distinguish between GROMs in the standard base and base 1.

Really? Thanks for the information, that's great! In that case I should be able to just copy-paste my existing code into a GROM slot above extended basic. It appears normal extended basic has a 32K GROM, so I could just use the topmost 8K GROM slot at >E000 in GROM space and I wouldn't have to change any of the existing code of extended basic

In this new discussion thread there's the question on how to load extended basic programs to a real TI today, if you just have a FIAD file. If someone only has a console and no other expansions, the StrangeCart can do this for normal TI Basic programs, since the serial port connection over USB supports XMODEM transfers and I have implemented the SCD1 disk. These transfers are not super easy, but not difficult either, you basically just need to issue a few commands over a terminal connection with a terminal supporting XMODEM. This feature is possible since TI Basic supports GROM based DSRs. My understanding is that Extended Basic does not search for DSR there but rather in the memory space >4000...>5FFF. So if I wanted to enable similar disk access from Extended Basic, I would need to modify extended Basic itself to be aware of the StrangeCart and use its services for SCD1. Any comments, is my understanding correct?

It is available in small quantities, as I assemble them manually... I think I still have a few ready to go and parts for more.

This is an interesting question, my StrangeCart cartridge (which hardly anyone has) is able to do this. I haven't really thought about this use case in the past, but if someone only has a bare console and wants to transfer TI Basic programs into it, my cartridge would help. It can't do that yet for extended basic programs, but is something I could add, although would require some effort from me due to differences how TI Basic and Extended Basic look for external devices.

Thanks for the detailed explanation, although I'm not sure where the 8 scroll offsets vertically come from. Need to think about this more. The version I posted on Saturday uses about 65000 clock cycles per frame (measured with my own emulator, so take it as a rough number) for the transfer from main memory to VDP, irrespective whether the frame is located horizontally in an even or odd pixel offset, since it's using separate source frame buffers for horizontally even/odd aligned frames. This translates to around 46 fps, although that probably gets scaled down to 30 fps since the code waits for frame sync before each swap of pattern definitions. I think for now this performance is high enough for me as a proof of concept, next need to think about what kind of a game would be interesting with these super chunky pixels Of course depending on the game scrolling might not b required, but developing this code which is also good for scrolling is a good way to understand what kind of screen update frequencies we can expect in general. Like I mentioned in the Pandemic Zoom call on Saturday, I'm intrigued by the idea of making a lunar lander, with Artemis happening and all

Next version of my demo, with a pretty decent frame rate. I tried rendering a couple of ways. The fastest I was able to come up with is this version, where the source frame buffer 128*64 is in memory in two versions: "normal" version and a version scrolled to the left by one pixel. The code is drawing a spinning object in there, which is drawn twice per frame, to both frame buffers (the normal and left shifted one). This approach allows fast writing to VDP RAM, without having to do shifting of the whole picture on each frame. Edit: the screen capture below is from js99er.net, and seems to show tearing, i.e. its partially updated about half way through. multicolor.asm MULTICOLOR.bin

Hopefully that would happen. Sadly I don't personally have one, although I do have a TI-74 which I like and I so much want to replace that screen with a small graphics color screen... But I don't want to butcher the otherwise fine TI-74. I like its keyboard. I love the portability, but no 16-bit CPU and the one line LCD is limiting.

Within the TMS9900 realm in addition to the TI-99/4A I'm interested in the Geneve, Tomy Tutor and the TI-99/2. Of course all three are based on the TMS-9995. @pnr made a FPGA version of the TI-99/2 (not sure if it's complete) and I have played with it. I find it interesting since it has a "normal" architecture: memory mapped frame buffer, no GROMs and I guess no GPL either. That architecture would be much better for BASIC. I just dug up the "TI992_Product_Specification.pdf" and indeed the memory layout is nice, no I/O devices breaking the memory map in the middle. Makes me think if I should build one myself, I recently acquired two more TMS9995 processors (still untested). Just use the existing spec and of course add color graphics

Here's another version about my silly multicolour test program (only tested on js99er - the single stepping disassembler behaves weirdly when debugging). This second version has two phases: - First phase is the same slow color bar thing as the earlier one, but now with double buffering in VDP memory and code to wait for VSYNC as per guidance from @Asmusr - Second phase is in my opinion more interesting. The code has what I call a playfield, which is 128*64 pixel bitmap on memory. From this playfield a give 64*48 pixel view is rendered to the display. The playfield window is "bounced" around and at each vertical bounce the horizontal direction is updated. Best to take a look to understand. The code does not yet know how to update the playfield from an odd pixel location, so horizontal scrolling bouncing is in steps of 2 pixels still. This code is now optimised (see below), although still running from cartridge memory. The playfield format is a linear frame buffer, with two pixels per byte, thus 4096 bytes for the whole playfield, out of which 1536 are copied to screen. @Asmusr was wondering about the best pixel format, I think the packed one is probably good, since it allows 16-bit loads from the playfield, which might be useful when adding pixel level horizontial positioning. Here is the inner loop: MULTICOLOR.bin multicolor.asm

Yes I will do that. This was literally a simple quick and dirty test only. I think the rendering should be done to a system RAM buffer, and then have an optimized routine to push the data to the VDP to avoid the constant need to set the VDP write address as I do now. The RAM buffer would also be needed to draw more involved graphics, since each byte has two pixels and therefore read operations are needed on blit edges. Anyway this is a fun little exercise.

Motivated by this discussion, I created a really simple and stupid assembler program to test multicolour mode. Attached assembler source and cart image MULTICOLOR.bin (tested with js99er only as I'm Mac user). While working at it, I noticed that in the table on TI tech pages there is a typo: the location of text mode and multicolour bits in VR1 is swapped. The register layout is like this: * VR1: 7 6 5 4 3 2 1 0 * VR1: 16K Blank Int Text Multi 0 Size4 Mag 2x Bit 7 is MSB, bit 0 LSB. Thus the sane bit order, not the TI one. Below is a screenshot. It just draws some vertical lines, which rotate from one frame to the next and then it draws a "sprite" i.e. just a multicolour bitmap on top. The code is not optimised at all. After working on the ARM chips, the TMS9900 code really goes on pedestrian speeds The code contains a routine I wrote MULTICOLADDR which calculates from X and Y the address of a pair of pixels in the multicolour mode memory layout. (If you wonder inconsistent spelling, the word color comes out of my spell checker as colour). If you want to mock around with the code, use XDT99 to assemble it. I unzip the result to get multicolor.bin, the cartridge image from the zipped rpk image. * Assemble with: * xas99.py -L multicolor.lst -R -c multicolor.asm * unzip -o multicolor.rpk MULTICOLOR.bin multicolor.asm

Somewhat off-topic and unnecessary advertising of my ET-PEB project: it does DMA transfers from SD card to CPU RAM expansion. The onboard microcontroller handles moving of data back and forth between CPU RAM and SD card, and translating to the FAT32 filesystem in between. Although personally I think it's cool, it's sort of pointless since all TI-99/4A software expects disk buffers to reside in VDP memory. Of course it's a requirement for a non-expanded system, and would be too easy otherwise. So in the end the CPU copying is still needed, and probably in many cases the first thing the application code does is to copy the buffers back to CPU memory

This may be a silly question, but would a trackball style mouse connected to a TIPI work? I guess at least if the game was modified a little

Yes I’ve also watched videos about this, interesting stuff. Is there any MIDI software for the TI? Or MIDI interface for that matter? I already built one for the TI myself

Thanks, will take a look!

I’d be happy to send you one. Just send a PM. And what is MPD?

It’s written in C, and it is a simple program. The benefit of C is that ST micro’s tools (STM32CubeIDE) make it easy to get the on-chip hardware initialized without reading 1000+ pages of the reference material. There are only a few hundred lines of real code once the hardware is set up. The whole thing could be ported to Forth. The tricky initialization code could be ported to Forth as well. I’ve looked at the code generated by mercisp (it comes with ‘see’) and it’s pretty damn good. I also really really like that its disassembler (and assembler!) both use postfix notation even if they’re written in forth. Further, the source code is written in normal assembler, making it easy to understand, it’s compiled with gcc’s assembler and not using some forth cross compiler (at least the parts I’ve looked at). When I have time I will try to see if the GROM service routine could just be an interrupt handler. I’m also interested in porting Mecrisp to the StrangeCart, to replace the simple shell I’ve written for it.

After spending quite a few hours today I have the first boards ready for shipment, trying to get them out the door tomorrow as I have business travel ahead. All kinds of new learnings when building these boards. Perhaps this is a good time to introduce the TI-GROMmy2 board: Form factor almost identical to the TI-GROMmy Uses STM32G070KB6 MCU. 128K Flash 36K SRAM 32-pin LQFP, pin pitch is a leisurely 0.8mm as opposed to the 0.5mm with the first grommy or most other boards I have recently worked on. Firmware lags behind TI-GROMmy. With both boards the functionality is quite minimal. The grommy2 extra flash is not yet used in any meaningful way, it just sits there. But the extra capacity means it can easily store multiple GROM images. The flash memory can be programmed with either a simple FTDI adapter or with ST-LINK2.1. I today learned how to configure the chip for serial port flashing. After bringing up the board I also ordered a NUCLEO-G70RB board, it has the same MCU but in a 64 pin package. I "ported" Mecrisp Forth for this board (there was almost no effort as there already was a version for NUCLEO-G71RB which is very similar). This might be interesting for the @TheBF and not hard to guess what firmware add-on I am planning for the TI-GROMmy2 I think the ported Mecrisp-RA probably would already directly run on my board, but both it and my firmware are baremetal versions, so I need to find some software glue and put these two together...

I had today time to work on building more TI-GROMmy boards. I built two different types of boards: TI-GROMmy version 0.2 boards, got three built and fully tested. These use new v.0.2 version PCB. Also started to build a batch of four TI-GROMmy2 boards, which I will describe later, hopefully in a video. I have also designed third board, now in its second generation. Overall in this TI-GROMmy project I have designed 5 different PCB layouts in total for various versions... Four of these work, the last one I haven't had the time to work on. I think I have in total ordered and received 80 PCBs so far, quite a few. I have also assembled the recent boards using new techniques to me, I went for low temperature solder paste (which is also lead free). I'm also using lead free solder for the components which cannot be soldered with solder paste. I'm using a hot plate to bake the boards with solder paste, and this speeds up the process quite a bit, especially with TI-GROMmy 0.2 boards which only have components on the top side. In the picture above on the right there are three finished TI-GROMmy 0.2 boards, top middle is one TI-GROMmy 0.1 board. I have modded it to behave as 0.2 boards. In the center is a TI-GROMmy2 prototype board (which works without any patching) and the remaining four are half built TI-GROMMy2 boards. Need to still populate the bottom of those boards with some passive components and the pin headers. But getting ready to send the first ones over.

Is this version of TI Basic GROMs available somewhere?

Yes I am aware of that, but still would be handy. This relates to having the ability to host multiple system GROM images at once, which is something my new boards support... A quick rant: One thing I really never understood is that why did BASIC's only provide 8-bit pokes? One of my retro computer systems is the Oric Atmos, and it has DOKE and DEEK features. DOKE is a 16-bit poke and DEEK is 16-bit peek. These would be especially handy with a true 16-bit system like the TI99/4A. Especially as the BASIC has no provision to simply and effectively break 16-bit words to bytes and vice versa. The 8052BASIC from Intel is another example of a nice BASIC with good bitwise operations. Of course BASIC was intended to be high level and beginner friendly, but in my personal opinion there was no harm (except a little ROM space consumption) to add these types of features.