StrangeCart

[+dhe]

Me #2

[+retroclouds]

I'd be interested in two.

[ti99iuc]

Hey @speccery I could be interested in two of them also if still available please  
One for me and one for @fabrizio

Edited April 12, 2021 by ti99iuc

[+Ksarul]

I'd be interested in one too. . .

[wierd_w]

One potential application for such a device, is compressed (or even procedural generated) content being made available JustInTime(tm) as if it were bank swapped memory.  The data is stored in compressed form (Say, using xz ?), and the MIPS chip is fed a decoding / "bankswitching" program when the accompanying program is executed.  (So it can say, emulate Write on ROM behavior to catch a bank switch).  Since the returned "pages" are just decompressed data from the compressed data fed into the cart's actual memory, they would be virtual pages. (The MIPS processor overwrites a single page of actual RAM with the uncompressed contents of the compressed page data in its other pages, and does not actual move the window.  It just loads the appropriate page into the decompressed page area as requested.) 

 

If procedural content is done instead, the content generation routine could be loaded into the cartridge's memory along with the procedural generation algorithm, and then the cartridge itself generates all the data the program needs, rather then trying to load it from diskette.  (Such as say, rules-based routines to generate mazes and collision definitions-- or generate random overworld maps for say, a zelda-like, using a random seed.)

 

Another interesting use would be as a compiler accelerator module. (say, a re-write of the BASIC compiler, that leverages the MIPS processor in this cartridge.)

 

There are a LOT of things this kind of gadget could be doing. 

 

(I rather like the idea of something like Linux's ZRAM;  The strangecart could be fed a program to create compressed virtual pages, and thus act like it can hold way more data than it actually can, and do so fairly transparently, because it can do the compression/decompression fast enough that the TI has no clue.)

 

 

 

 

 

 

 

[+dhe]

1 hour ago, wierd_w said:

because it can do the compression/decompression fast enough that the TI has no clue.)

 

Ok, now your just messing with the old guy (the 9900) - what next? Hide his keys? ?

[wierd_w]

Not really?

 

See for instance, the zstd compression algo used by ZRAM.  It is able to pretty reasonably get at least 3:1 compression on normal RAM contents. (worst case is that you load the entire page with uncompressable data of course.)

 

 

Here you see ~101mb of swap allocated in the zram pool, packed into ~21mb of space, for a ~5:1 compression rate.  zstd packs that stuff hard.

 

Instead of packing swap though, we would be packing normal memory pages.  (the zram algo already works as arbitrary pages, btw.)

 

Since memory accesses are heavily hobbled by waitstates in the TI, you have multiple execution cycles of the 9900 in which to do the needful to:

 

1) Catch the bankswitch trigger

2) write the current uncompressed page into its appropriate compressed page.

3) Read the requested compressed virtual page, and uncompress it into the uncompressed page inside the window.

 

From the 9900's point of view, it looks as if a normal bankswitch occurred. (it has no clue.)  However the MIPS processor is doing the heavy lifting to implement somethig akin to zram's algorithm, with zstd compression, to make the small amount of RAM it has onboard the strangecart look and feel like it is many many times larger, by leveraging the fact that it is many many times faster than the TMS9900.

 

 

 

 

[speccery]

3 hours ago, wierd_w said:

One potential application for such a device, is compressed (or even procedural generated) content being made available JustInTime(tm) as if it were bank swapped memory.  

This is sort of what my test software does already: the ARM core draws some test graphics, generates code for the TMS9900 to load the graphics into VDP memory, alerts the TMS9900 that code is ready. The TMS9900 starts to write stuff to VDP memory, and the ARM renders the next frame in parallel. From the ARM's point of view the TMS9900 takes ages to write the stuff, so it has plenty of time. The TMS9900 code is basically a long string of "load workspace register immediate" instructions, with the workspace pointing to the VDP. In the time each LI instruction executes (24 clocks at 3MHz i.e. 8 microseconds) the ARM core can run up to 768 instructions, in practice somewhat less than that (due to flash memory wait states and some instructions taking more than 1 cycle).

 

Once the TMS9900 is done with the VDP memory writes (basically it reaches the end of cartridge ROM area), it writes to a magic memory location, and the ARM generates another 7.5K bytes of instructions for it. Once that's done, the TMS9900 is signalled to execute the next batch, and os it goes. This could be done with bank switching, but the ARM generates the 7.5K of code so quickly that in my initial tests the TMS9900 code only runs about 2% slower as it is waiting for the ARM to do its thing. This is quite a difference, since the TMS9900 only executes the simplest of instructions, the LI instruction, while the ARM has to do quite bit of computation to transform the frame buffer in its memory into a TMS9900 instruction stream.

[speccery]

4 hours ago, Ksarul said:

I'd be interested in one too. . .

 

If I counted correctly it would seem there is interest for 7 boards at this point. I am glad to see that. Good to keep in mind that I consider all of these boards being prototypes. The V1 prototypes have only been tested on two of my consoles, so more testing definitely needed. I don't know if the StrangeCart somehow interferes with other peripherals. It shouldn't, but I have only tested it with ET-PEB boards. Those two work fine together.

 

The limiting component for builds at the moment is the MCU, which is in short supply. I think I have around 15 of them in stock at the moment. The PCB order should come in today, there are 10 boards. The new revision is of course untested at this point. Getting more PCBs is easy, once I know the boards work.

[+acadiel]

5 hours ago, speccery said:

 

If I counted correctly it would seem there is interest for 7 boards at this point. I am glad to see that. Good to keep in mind that I consider all of these boards being prototypes. The V1 prototypes have only been tested on two of my consoles, so more testing definitely needed. I don't know if the StrangeCart somehow interferes with other peripherals. It shouldn't, but I have only tested it with ET-PEB boards. Those two work fine together.

 

The limiting component for builds at the moment is the MCU, which is in short supply. I think I have around 15 of them in stock at the moment. The PCB order should come in today, there are 10 boards. The new revision is of course untested at this point. Getting more PCBs is easy, once I know the boards work.

Be glad to test one too.  I’ve got just about everything and the kitchen sink here as well.

[Asmusr]

My interest is more theoretic at the moment. Knowing that the cart exists is inspiration for thinking about new game projects. But if I was to develop anything I would want to set up an emulated environment first. 

[+Ksarul]

And I can definitely test them against almost every strange hardware configuration known to the TI world. . .I have a good reference set of useful hardware.

[Elia Spallanzani fdt]

Imagine a game like "another world": the microprocessor on the cartridge could calculate the vector scenes based on the keys pressed on the ti99 and send the result to the vdp many times per second, perhaps only the differences between one frame and the previous one in order to use less bandwidth?

 

p.s. indeed, maybe you could even put an emulator on the cartridge and run the games of the msx or spectrum or other computers and "project" the video and sound output on the ti99, making it convert on the fly into the suitable format?

Edited April 13, 2021 by Elia Spallanzani fdt
Addetto p.s.

[speccery]

1 hour ago, Elia Spallanzani fdt said:

Imagine a game like "another world": the microprocessor on the cartridge could calculate the vector scenes based on the keys pressed on the ti99 and send the result to the vdp many times per second, perhaps only the differences between one frame and the previous one in order to use less bandwidth?

 

p.s. indeed, maybe you could even put an emulator on the cartridge and run the games of the msx or spectrum or other computers and "project" the video and sound output on the ti99, making it convert on the fly into the suitable format?

thanks for the comments.

I have actually written video encoders and decoders in my past jobs. Real-time encoders for MPEG-4 for instance... running a video decoder could be fun, but it would require a custom codec.

 

The thought of emulation did cross my mind too, I was actually thinking about the spectrum and also CP/M as options. The VDP memory bandwidth is low compared to the Spectrum, but it could be done. There are many possibilities, but need to think about the software architecture and keep

the project scope from becoming too big.

[+Schmitzi]

 

Hi @speccery great and interesting doing ?   If still possible I am in with 1    thx

 

ACK ACK ACK

 

Edited April 13, 2021 by Schmitzi
Edited for ACKnowledgement ?​

[speccery]

9 hours ago, Schmitzi said:

 

Hi @speccery great and interesting doing ?   If still possible I am in with 1    thx

 

ACK ACK ACK

 

Yes that should be fine.

 

I did some recalculation of the BOM, the range I provided before was lacking the PCB price and VAT I needed to pay for the parts. I think I will set the price of the prototypes / first batch to around 50 EUR each + shipping. That would enable me to recoup the price of the components and prototype boards. I can't really put a price on the manual assembly and testing work, otherwise the price becomes stupid. 

 

[speccery]

The PCBs arrived yesterday evening, at the last hour of delivery. I was eager to start building, but no energy left at that point. Instead I just used a multimeter to check the board. At least everything is not shorted and this PCB fits into a cartridge case nicely! My silkscreen design job is far from perfect, but much better than with the previous boards.

[TheMole]

I'd like one as well, but will be moving continents soon (June), so do you reckon I could get one here in Belgium before that?

[speccery]

30 minutes ago, TheMole said:

I'd like one as well, but will be moving continents soon (June), so do you reckon I could get one here in Belgium before that?

Yes should not be a problem. I am in the process of acquiring more components, so hopefully the chip supply will not be a problem.

[TheMole]

Cool! Then feel free to add me to the list

[speccery]

Built first V2 board and did some quick firmware modifications to support the new board. It worked straight out the bat, as far as I tested. Zaxxon demo ran as beautifully as ever.

I need to work on the firmware to support the flash chip; having that there enables so many things.

 

I spent at almost 3 hours building it, since I wanted to try out the stencil I ordered, but it really just slowed me down. I think the solder paste I had was old, and at the end of it I had to resolder many components since the paste was all over the place. I also soldered the MCU again. I don't have reflow oven, so it was just a frustrating experience with the SMD hot air gun.

 

One design error is that the SWD debug connector (top right hand corner) is too close to the reset button, so I needed to mount a flat button as the debug cable connector was surprisingly wide. I am not planning to include the connector anyway on all boards, since it's not really needed. I haven't tested the SWD connector on the board yet, just flashed the MCU through the USB port.

[+9640News]

I am interested in a board if they are all not already spoken for.

 

[speccery]

Got a good question about the test/prototype nature of the board, and whether there would be a "final" version of the board, I thought I share my answer with everyone interested:

 

I spoke about test version or prototype, because the board has only been tested by me in very limited hardware environments. There's a possibility it's not compatible with something important, such as the normal PEB. If during more extensive testing - done by others independently from me - compatibility issues requiring hardware changes do not arise, this can be the final version. 

 

There are two features which could be nice to have: SD card support and audio DAC. But there are connectors (well holes in the PCB for a pin header ?) for both, so they can be added to this version already. For the sake of simplicity I'd like to keep this board quite plain, it actually makes the thing more versatile. If for instance audio DAC is included, it means that some of the now free pins will be spoken for, and that may limit other experimentation. No promises for further development though...

 

Regarding RAM capacity: The MCU has 192K of RAM. Some of that is needed for housekeeping tasks, but I could imagine a Basic with 128K of free RAM.

[wierd_w]

I would suggest that the audio DAC and pals, either route audio out through an RCA port, OR-- To accompany the device with a sidecar adapter board. (Has a cardslot, and then an IDC cable for the other signal wires, including the audio out line.)

 

That way it could be installed in either configuration.

[Asmusr]

I'm curious about what those people lining up to buy the board expect to be using it for at this stage? Personally I wouldn't have any idea how to program the cart.

Edited April 15, 2021 by Asmusr